Using low power mobile SDRAM with SAM-BA

Omar · **Posted:** Sat May 16, 2009 6:44 pm

I have made a board based on the AT91SAM9261-EK development board but with low power (1.8v) SDRAM and NAND memories, only one of my first prototype boards is accessible through SAM-BA (very unstable though). Any suggestion on what parameters should be adjusted in the SAM-BA applets? I don't have problems compiling the applets but I keep getting the "Fail to initialize external RAM" message on all the other boards.

csagonero · **Joined:** Mon Jul 27, 2009 5:01 pm **Posts:** 8

Hi,

Apparently, we have the same problem ... We develop a board based on the AT91SAM9G10 :P
We use two mobile lpsdram chips from Micron : MT48H32M16LFBF (datasheet attached)

We modified applets code and compiled with succeed. (code attached too)
But every time, we have the same error "Fail to initialize external RAM" ( 0x0F )

Any help will be appreciated

Thanks

Edit : sam-ba version 2.9

Ithinuel · **Joined:** Tue Jul 28, 2009 10:48 pm **Posts:** 4

Hi,

I'm working on the same board as csagonero.

Code:

void BOARD_ConfigureSdram(unsigned char busWidth)
{
[[ send me a PM for futher information ]]
}

I checked at least ten times my code.

So, i tried to bypass the ExtRAM_TestOk test so that it returns always 1.

Sam-ba tells that it succeed in initializing sdram.
Then I tryed to send on the SDRAM the at91sam9g10 datasheet wich is about 11MB.
I used the "compare sent file with memory" tool, it told me that it was the same thing.
I read the data into a new pdf file wich, indeed, was good.

So i don't understand why the ROM (Sam-Ba) can interact with sdram, whereas my applet in sram do not.

We have 2 at91sam9260-ek.
We notices that several sources running on at91sam9260ek has code wich does not correspond to the comments.
They often configure LMR by writing some datas on SDRAM_BASE_ADDR (0x20000000) whereas we can read in the sdram's datasheet that at least CAS Latency has to be configured with the value 2 or 3.

Maybe am i missing something about the hardware operations.

We modified the configuration value in void BOARD_ConfigureSdram(unsigned char busWidth).
Seeing that it had no real effects we did this

Code:

void BOARD_ConfigureSdram(unsigned char busWidth)
{
    volatile unsigned int i;
    static const Pin pinsSdram = PINS_SDRAM;
    volatile unsigned int *pSdram = (unsigned int *) AT91C_EBI_SDRAM;
    unsigned short sdrc_dbw = 0;
    unsigned int tmp = 0;

    switch (busWidth) {
        case 16:
            sdrc_dbw = AT91C_SDRAMC_DBW_16_BITS;
            break;

        case 32:
        default:
            sdrc_dbw = AT91C_SDRAMC_DBW_32_BITS;
            break;

    }

    // Enable corresponding PIOs
    PIO_Configure(&pinsSdram, 1);
    
    // Enable EBI chip select for the SDRAM, VDDIOMSEL set: memories are 3.3V powered
    tmp = READ(AT91C_BASE_MATRIX, MATRIX_EBI) | AT91C_MATRIX_CS1A_SDRAMC;
    WRITE(AT91C_BASE_MATRIX, MATRIX_EBI, tmp);

    // CFG Control Register
    WRITE(AT91C_BASE_SDRAMC, SDRAMC_CR, AT91C_SDRAMC_NC_9
                                        | AT91C_SDRAMC_NR_13 
                                        | AT91C_SDRAMC_CAS_2 
                                        | AT91C_SDRAMC_NB_4_BANKS
                                        | sdrc_dbw
                                        | AT91C_SDRAMC_TWR_2
                                        | AT91C_SDRAMC_TRC_7
                                        | AT91C_SDRAMC_TRP_2
                                        | AT91C_SDRAMC_TRCD_2
                                        | AT91C_SDRAMC_TRAS_5
                                        | AT91C_SDRAMC_TXSR_8);
/*/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////     comment this on a desperate attempt to understand how it does work...
    for (i = 0; i < 1000; i++);
[...]
    WRITE(AT91C_BASE_SDRAMC, SDRAMC_TR, (BOARD_MCK * 7) / 1000000);        // Set Refresh Timer
*//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////     comment this on a desperate attempt to understand how it does work...
    WRITE(AT91C_BASE_SDRAMC, SDRAMC_MR, AT91C_SDRAMC_MODE_NORMAL_CMD);    // Set Normal mode
    pSdram[0] = 0x00000000;                        // Perform Normal mode
}

compiled successfuly
loaded on the target
run ...
It works fine ...
Guess why ... probably one of the unpredictable cases.

Any clue is welcome.

Best regards.

PS :
My Toolchain works well, i built it with openembedded.
I had some trouble with "__rent" undefined, "vprintf" defined two times, or "__aeabi__uidiv" undefined, etc.
I managed to solve it by adding missing elements (__aeabi__uidiv, __div0, ...) or by passing the others (__rent, __aeabi_idiv, ...)
I also added the "-nostdlib" token in LDFLAGS so that it does not link against my gcc-coss libs but only the objects files provided in the utilities of sam-ba applets.

Ithinuel · **Joined:** Tue Jul 28, 2009 10:48 pm **Posts:** 4

Hi,

We managed to make it work !!!

[[ send me a PM for futher information ]]

Thanks for all your reply.

Best Regards

socrates · **Posted:** Sun Aug 02, 2009 8:50 pm

Hello,
we have some strange problem too using AT91SAM9260 in LQFP208. We use Micron MT48LC16M16A2 SDRAM (the same as it is in development board) with 3.3V and sometimes, SAM-BA 2.9 shows that it has failed to initialize external RAM. Sometimes it works OK, but if I try to write for example 100 bytes FFFFFFFF, I get something like random numbers and 8 to 16 bits filled normaly. Example: ff the current 32 bytes are 55555555 I write all FF, I get 55FF5555. Otherwise, if I use SAM-BA 2.0, it always succeed initializing external RAM without any errors, and sometimes it writes normally to RAM (all FF example). I've checked all address and DATA signals, all OK, also I see signals on CAS and RAS, CS works normally. Is it possible that it could be soldering problem or maybe someone have other ideas? Thanks.

P.S. sometimes = not always!

socrates · **Posted:** Mon Aug 03, 2009 9:19 pm

I found that there was a pin soldered not correctly, anyway, now SDRAM initializes fine, but works bad. Here is the problem:
if I write for example 11 22 33 44, the 4th byte will overwrite the 2nd one (I count from 1, not 0), so the result will be: 11 44 33 44.
if I write 11 22 33 and the 4th is left, then it writes correctly, so I see that 4th byte overwrites the 2nd one, but I can't find what is the problem. I've checked address pins, also DATA pins, everything connects fine. Is it possible that:
1. Address pins are shorted?
2. Data pins are shorted?
3. Bad RAM chip?

P.S. if I write 11 22 33 44 55 66 77 88, the result is 11 44 33 44 55 88 77 88, as you can see, every 4th byte, overwrites the second one everywhere.

Using low power mobile SDRAM with SAM-BA

Who is online