Good day, friends!

I create PCB with at91sam9g45 + DDR2 (multiport) chip - MT47H32M16. I can't work with this DDR2.
In standart library file board_memory.c i find some mistakes:
Use config branch for DDR_SAMSUNG_M470T6554EZ3_CE6, in step 16 configure EMRS1 (write to addres *(pDdr+0x1000000) in step 18 again write to EMRS1, but write to address *(pDdr + 0x3000000). Why in steps different address for the same external register?

p.s. my memory is single chip MT47H32M16. I use config branch for DDR_SAMSUNG_M470T6554EZ3_CE6 because it is the same numbers of columns and rows.

Thanks!

Hi,

I'm running the AT91SAM9G45 with MT47H32M16HR-3. I've edited at91sam9g45ekese.c to change the number of rows to 13:
static SDdramConfig ddram_config = {
..
AT91C_DDRC2_NR_13 | // 13 row bits (8K)
..
}

This seemed to work ok at first, u-boot loads and linux boots. Although after using it for a while longer i'm noticing some strange things, for example if i try to copy a large file to memory i get a kernel panic and the board reboots.

Still investigating but did you see anything like this or have you found a solution to your problem?

I've solved this issue, I though the change for the number of rows within at91sam9g45ekes.c would have flowed onto the relevant parts of code, but ddramc. 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 help to someone else.

Also check http://www.at91.com/forum/viewtopic.php/t,19409/ this for more info.

p.s. I agree with your original comment, steps 16 and 18 seem to disagree with the datasheet.

[quote="please_work"]I've solved this issue, I though the change for the number of rows within at91sam9g45ekes.c would have flowed onto the relevant parts of code, but ddramc. 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 help to someone else.

Also check http://www.at91.com/forum/viewtopic.php/t,19409/ this for more info.

p.s. I agree with your original comment, steps 16 and 18 seem to disagree with the datasheet.[/quote]


Thank you for reply!
I will try your recomendations. But i use not ES silicon. In my board i solve problem - it was some problems with CLK signals (routing board mistakes). Now i solder samsung memory K4T51163QI and all seems fine. Use standart procedure for config EBI0 DDR2 controller, and all tests passes ok. But i don't understand why it works - "..16 and 18 seem to disagree with the datasheet" ... but it works. May be DDR2 controller state machines resolve this

Some Notes as I switched to a LPDDR IC on my custom board.

// Note: Bank Select Offsets for 128 MByte by 16 bit DDR
// 1 Bit Byte Select
// 14 Bits Row Select
// 10 Bits Col Select
// 2 Bits Bank Select
// 4 Bits Chip Select
// BA[10] = 00 = 0x0000000
// BA[10] = 01 = 0x2000000
// BA[10] = 10 = 0x4000000
// BA[10] = 11 = 0x6000000

// Note: Bank Select Offsets for 256 MByte by 16 bit DDR
// 1 Bit Byte Select
// 14 Bits Row Select
// 11 Bits Col Select
// 2 Bits Bank Select
// 4 Bits Chip Select
// BA[10] = 00 = 0x0000000
// BA[10] = 01 = 0x4000000
// BA[10] = 10 = 0x8000000
// BA[10] = 11 = 0xC000000

Hi Guys,

we got stability Problems using the MICRON MT47H32M16 under high DDR-BUS load.
When doing things like building CRC's oder large FFTs. The Problem is getting worse when disabling I and D cache.

Anyone here so kind to post the initialization sequence for MT47H32M16 ?

Big thanks in advance.

Cheers Dr

I don't know this for sure, but i'd say if you can run mtest in u-boot without problems its not going to be an initialisation problem.

Have you checked your voltages under load? Also are the trace lengths all matched?

Guys,

I've got a custom 9M10 board with LPDDR, and it's giving me a headache. Your past comments have been quite helpful before, hence my cry for help in this thread:

1) I have recompiled all applets for SAMBA to initialise the memory, and the internal memory test works flawlessly
2) I can read/write to the dataflash on the board without problems. AT91Bootstrap works fine, until the jump to 0x70000000, after which the board simply stops
3) with a SAM-ICE attached, I can do everything in SAMBA, but the NAND flash applet does not work in DDR. When I recompile to run in SRAM and let it run there, it works fine, except for programming, due to the buffer being too small. Erase/scrub/list bad blocks all works fine.

When inspecting the memory from AT91Bootstrap, the memory dump is a 1:1 copy of the file it ought to copy to the memory. Also in SAMBA there is a close match (but SAMBA has its own quirks apparently in reading out the memory)

So in short, anything I try to <i>run</i> out of DDR doesn't work, whilst copying and reading from/to works fine. I have the impression its cause should lie somewhere in the linker files, but they are the standard ones which came with the SAM-BA applet files (v2.11).

Would you happen to have any clues as to what the cause could be?

P.s. I am using the latest CodeSourcery g++ compiler.

Given these set of circumstances, I guess I'd try playing with the AT91BootStrap code, and add assorted diagnostics, monitor and code download features to probe the hardware further.

It should also be possible to step into AT91BootStrap and the DDR code using the SAM-ICE with either JLINK.EXE or a suitable ARM debugger.

If you can confirm the code downloaded to DDR is valid, with say a CRC32 check compared to a value computed on the PC, and can repeat that a couple of minutes later, it would suggest the memory is indeed intact, and can refresh properly. Step into the code and see where it goes.

You could add code to output to the debug USART as the first thing it does, and perhaps take some steps into the existing code as see how long it lives. If you have an LED you could try initializing that in the bootstrap code also, and then toggle or blink it along the way. If you just sat in a tight loop echoing USART characters, or blinking a LED, you'd at least know it's not completely dead.

Now at a guess, I'd say the compile address is wrong, or setting up the cache, or stack, or the remapping at zero, are failing. If it touches some memory inappropriately it may well end up in the abort vector.

You could confirm the compile address of the code going into DDR, you could disassemble it with something like objdump, and walk through it.

I must admit SAM-BA has turned into rather a cluster over the years, I'd be a lot more temped to inject code with something like Keil and tinker with bringing up the hardware that way. With a better grasp of what the hardware is actually doing or not-doing, you might have a chance at getting SAM-BA up.

[quote="CptTitanic"]Given these set of circumstances, I guess I'd try playing with the AT91BootStrap code, and add assorted diagnostics, monitor and code download features to probe the hardware further.

It should also be possible to step into AT91BootStrap and the DDR code using the SAM-ICE with either JLINK.EXE or a suitable ARM debugger.

If you can confirm the code downloaded to DDR is valid, with say a CRC32 check compared to a value computed on the PC, and can repeat that a couple of minutes later, it would suggest the memory is indeed intact, and can refresh properly. Step into the code and see where it goes.

You could add code to output to the debug USART as the first thing it does, and perhaps take some steps into the existing code as see how long it lives. If you have an LED you could try initializing that in the bootstrap code also, and then toggle or blink it along the way. If you just sat in a tight loop echoing USART characters, or blinking a LED, you'd at least know it's not completely dead.

Now at a guess, I'd say the compile address is wrong, or setting up the cache, or stack, or the remapping at zero, are failing. If it touches some memory inappropriately it may well end up in the abort vector.

You could confirm the compile address of the code going into DDR, you could disassemble it with something like objdump, and walk through it.

I must admit SAM-BA has turned into rather a cluster over the years, I'd be a lot more temped to inject code with something like Keil and tinker with bringing up the hardware that way. With a better grasp of what the hardware is actually doing or not-doing, you might have a chance at getting SAM-BA up.[/quote]

Thanks a million, at least you've ensured me I wasn't as crazy as I thought I was.

I checked the memory contents over and over, and they were right every time, so no luck there. (SAM-BA monitor however could really use a make-over, because it lists random values...)

Objdump told me my compile was right (or at least, that's the way I interpreted it), but I've gone back to the init sequence for the LPDDR.
I had followed the datasheet of the memory device to the letter (which differed somewhat from the 9M10 datasheet procedure), and thought of removing that, in a desparate attempt. Whilst going through all timing parameters and settings I noticed the mode setting for "step 8" was wrong - it should have been 3 but was at 5. That changed pretty much the whole game, and the SAMBA applets are now running fine.

Once again, thanks a million! I can now start debugging the real application ;-)