Against some odds, our G45 custom board is now running, and this time has the 22R padding resistors in the memory bus. The ddr memory is Micron MT46H32M16 which is a 64 Mbyte LP (Mobile) DDR, connected to the DDR controller. Surprisingly, after configuring the various ddr parameters it nearly worked straight away, and after several hours of diligent work it remains exactly the same in this nearly working stage! We have 2 prototypes and the problem manifests similarly on each one, so it seems unlikely to be an assembly fault, which leaves the possibility of a design fault, or (hopefully) just a ddr configuration fault. Boards are well decoupled, with short traces and good power planes.

Has anyone seen anything like this? Does it look like a ddr configuration fault?? (All ideas appreciated,thanks, Don)

Fault is best illustrated by the file written to ddr and then read back as follows:-

Wrote this to start of RAM:

ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz


Read back this (hex dump):

0000000: 41 42 43 44 ff ff ff ff 41 42 43 44 ff ff ff ff ABCD....ABCD....
0000010: 41 42 43 44 51 52 53 54 41 42 43 44 51 52 53 54 ABCDQRSTABCDQRST
0000020: 65 66 67 68 51 52 53 54 65 66 67 68 51 52 53 54 efghQRSTefghQRST
0000030: 65 66 67 68 75 76 77 78 65 66 67 68 75 76 77 78 efghuvwxefghuvwx
0000040: 55 aa 55 aa 75 76 77 78 55 aa 55 aa 75 76 77 78 U.U.uvwxU.U.uvwx
0000050: 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa U.U.U.U.U.U.U.U.
0000060: 55 aa 55 ab 55 aa 55 aa 55 aa 55 ab 55 aa 55 aa U.U.U.U.U.U.U.U.
0000070: 55 aa 55 ab 55 aa 55 ba 55 aa 55 ab 55 aa 55 ba U.U.U.U.U.U.U.U.
0000080: 55 aa 55 aa 55 aa 55 ba 55 aa 55 aa 55 aa 55 ba U.U.U.U.U.U.U.U.
0000090: 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa U.U.U.U.U.U.U.U.
00000a0: 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa U.U.U.U.U.U.U.U.
00000b0: 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa U.U.U.U.U.U.U.U.
00000c0: 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa U.U.U.U.U.U.U.U.
00000d0: 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa U.U.U.U.U.U.U.U.
00000e0: 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa U.U.U.U.U.U.U.U.
00000f0: 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa 55 aa U.U.U.U.U.U.U.U.

This turned out to be a red herring related to problems with Sam-ba 2.9. After building the applets for Sam-ba 2.10 everything starting behaving properly.

The biggest clue that led us here was that getting the SD RAM applet to do its own memory test revealed no memory issues.

Good day!
Kiwi, have you solve this problem? I'm using G45 and DDR MT47H32M16 and have problems with it configuration too. I don't understend why in board_memories.c procedure BOARD_ConfigureDdram() there is no writing to MR, EMRS1,EMRS2,EMRS3 next information: burst length, burst type and so on - all bits are "0" (except bits BA0/1 - address of MR,EMR1...)
Thanks

Hi,

What did you need to end up changing in the AT91SAM9G45 bootloader to get the DDR configured properly?

I've listed to change I had to make and the problems i'm still having here:http://www.at91.com/forum/viewtopic.php/p,33524/#p33524
http://www.at91.com/forum/viewtopic.php/p,33524/#p33524

Basically i get this running mtest from low to high memory addresses:
mtest 0x71000000 0x72F00000

Pattern 00000000 Writing... Reading...
Mem error @ 0x72E7EB68: found 73F269BA, expected 0079FADA

Mem error @ 0x72E7EB6C: found 72E7EB68, expected 0079FADB

Mem error @ 0x72E7EB70: found 72E7EB68, expected 0079FADC

Mem error @ 0x72E7EB74: found 0079FADC, expected 0079FADD

Just trying to figure out if this is hardware/software issue.

Thanks in advance.

You should probably go over all the array and timing parameters with care.

Drop the MCLK speed, and adjust the refresh, and try accessing/testing the array more slowly (100 MHz vs 133 MHz). Check to see if it is a marginal timing issue. Try several boards.

Add testing code into AT91Bootstrap, it runs in SRAM so could test the entire DDR array.

Make sure the hardware design is right, double check the symbols, part documentation, connectivity nets in the schematic.

Hi,

Thanks for the quick reply and advice. I'll give your suggestions a go.

Thanks for your help.

I've solved this issue, I thought the change for the number of rows within at91sam9g45ekes.c would have flowed onto the relevant parts of code, but ddram.c requires manually editing for writes to BA[1] and BA[0] based on the number of rows. I now have:

*((unsigned int *)(ddram_address + 0x2000000)) = 0; // Was 0x4000000 - shifted right by 2 to adjust for 13 row bits (See pg233 of AT91SAM9G45 datasheet)

Personally i would used the already defined constant for the number of rows to generate the value above but anyway.

And for the record i debugged in the following order:
- Checked if the problem occurred on another board - and had identical issues
- Checked if the problem occured on the other DDR bus (second EBI bus) - which it did
- Started looking for DDR config issues and re-reading DDR setup in datasheet.

Hope this can be helpful to someone else.