Dear everyone,

I am developing a second level bootloader for the SAM9x25-EK board. I have written a small bootloader that loads from the memory card into the internal memory of the device. The intention is that the bootloader should load another (larger) program into the external memory. The loading of the external memory, however, is causing me some problems.

When I use GDB (through Eclipse) I can see that the data that I have written to the external memory is "slightly wrong". I get:

0x20000000 E10F0000 E1A000C0 E129F000 E59F0000
0x20000010 E59F00A0 E15110A0 E59F20A0 00020002
...

Where I was expecting:

0x20000000 E10F0000 E38000C0 E129F000 E1A00000
0x20000010 E59F00A0 E59F10A0 E59F20A0 E1510002
...

The disassembly view also shows the wrong instructions compared to what I was expecting. When executed the code also does not work properly (the instructions shown in the disassembly view are probably also those that are being executed).

The obvious cause of this is that the data written to the memory is wrong and that I have a bug somewhere in my code. My, problem, however, is that I cannot verify this: If I dump the contents of the external memory (printf..) to the debug console I see the correct values!

This leads me to believe that there is some problem with the initialization of the external memory or the chip itself. I am using the setup routines (LowLevelInit, BOARD_ConfigureDdram etc.) provided by Atmel as part of the software package for the SAM9x25. Note that I do not have any problems downloading and executing programs in the external memory when I transfer them directly using the JTAG.

Any ideas as to what might cause this (and perhaps how to fix it!) are greatly appreciated.

Thanks
Peter

I finally had a breakthrough in my investigations of the problem:

If I move BOARD_ConfigureDdram() and BOARD_Remap() to the main function then the problem goes away.

I'd like to know why this is the case ...

Hard to know without reviewing the exact code flow you have.

It could relate to where you have certain clocks configured wrt to the ddr/sdram configured. If for example you're still running at 48 MHz

It could relate to where your stack is situated, needs to be in SRAM.

Attaching JTAG typically involves a script which initializes the DDR/SDRAM and the PLL into appropriate states before downloading or starting code.