Unable to load and run bare metal program in DDR from SDK 2015.2

Question

Hello all,
I'm starting to work with Zynq and I'm quite a noob in this field.
I generated a system for a ZC702 board in which the connections to the DDR memory and the GPIO are correct.
When I try to run a "Hello world" example that writes such words via serial, I'm facing the problem that I can just run it from the internal ram on the Zynq, not from the DDR. I will try to explain this with more detail.
When I set the on-chip memory (initial address is 0x00000000) on the linker script and I run the program, the XMD console shows this:
XMD% Processor started. Type "stop" to stop processor
User Interrupt, Processor Stopped at 0x00101104
Processor Reset .... DONE
Downloading Program -- D:/50_EXPs/080715/Zynq_702_projects/zynq_book/zynq_book.sdk/hello_world_gpio/Debug/hello_world_gpio.elf
section, .text: 0x00000000-0x0000191b
section, .init: 0x0000191c-0x00001933
section, .fini: 0x00001934-0x0000194b
section, .rodata: 0x0000194c-0x00001963
section, .data: 0x00001968-0x00001ddb
section, .eh_frame: 0x00001ddc-0x00001ddf
section, .mmu_tbl: 0x00004000-0x00007fff
section, .init_array: 0x00008000-0x00008007
section, .fini_array: 0x00008008-0x0000800b
section, .bss: 0x0000800c-0x0000802f
section, .heap: 0x00008030-0x0000842f
section, .stack: 0x00008430-0x0000a02f
Download Progress.10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x00000000
As you can see, al the addresses are correct. In this moment, the processor executes the program and everything is fine.
Then, if I select the DDR memory (initial address: 0x00100000) on the linker script generation, the console shows:
XMD% Processor started. Type "stop" to stop processor
Software Breakpoint 0 Hit, Processor Stopped at 0x000015bc
Processor Reset .... DONE
Downloading Program -- D:/50_EXPs/080715/Zynq_702_projects/zynq_book/zynq_book.sdk/hello_world_gpio/Debug/hello_world_gpio.elf
section, .text: 0x00100000-0x0010191b
section, .init: 0x0010191c-0x00101933
section, .fini: 0x00101934-0x0010194b
section, .rodata: 0x0010194c-0x00101963
section, .data: 0x00101968-0x00101ddb
section, .eh_frame: 0x00101ddc-0x00101ddf
section, .mmu_tbl: 0x00104000-0x00107fff
section, .init_array: 0x00108000-0x00108007
section, .fini_array: 0x00108008-0x0010800b
section, .bss: 0x0010800c-0x0010802f
section, .heap: 0x00108030-0x0010842f
section, .stack: 0x00108430-0x0010a02f
Download Progress.10.20.30.40.50.60.70.80.90.Done
Setting PC with Program Start Address 0x00100000
 But the program is not run and the processor is like "blocked".
There is just one scenario in which this second configuration works, and it's when the on-chip memories were previously loaded with the first configuration. This could indicate that the program counter is not pointing to the DDR, but to the on-chip memory. Then, when I select the DDR, if there is nothing on the memories of the chip, it does not execute anything.
Does anyone have any idea of what's exactly happening and how to fix it?
Thanks in advance!
Ignacio.

Answer 1

Hello, bwiec,
thank you four your response. I tried what you suggested, and it worked with no problem. I set the linker script so to store everything in OCM and executed the following piece of code:
u32 *memPtr;
u32 dataRead;
memPtr = 0x00100001; /* DDR address */
*memPtr = 0xdeadbeef;
u32 dataRead = *memPtr;
The value of dataRead is 0xdeadbeef;
So, apparently that was not the problem. But, fortunately, I found the solution to this issue. I will give the details in case it is useful for more people.
After triying to isolate the problem, I got to the following situation (I have been always working in SDK 2015.2):
A project created with SDK 2014.2, with Hardware Platform Specification, Board Support Package and C project was working fine.
The linker script of this project was indicating DDR usage in all the cases.
The BSP was using Standalone OS 4.1
When clicking Run, everything was working.
I performed a board reset to clean the DDR.
Then, if I changed the BSP to one created with the current version of SDK (2015.2), then the DDR memory was not being loaded properly, so the PC of the processor was pointing to the DDR base address but in that position there was no instruction, so it "blocked".
Then if I changed the "Referenced BSP" to the original one, it worked again.
If I went back to the 2015 BSP, then it worked, because the DDR was already loaded.
If a reset of the board was performed, the project referencing the 2015 BSP stopped working, because the DDR memory was again empty and not being loaded.
At the end, with the help of a coleage, I was able to find the problem, even though I don't really understand why this made my desing not to work:
The SW16 of the ZC702 board was set to: SW16(1 to 5) = "00010". This configuration:
Works with the BSP 2014 - referenced projects and the generated ".elf" files.
Does not work if the C projects point to a BSP generated in SDK 2015.2, because the DDR is not loaded.
The configuration that works for both cases is SW16(1 to 5) = "00000".
I personally don't understand exactly what's wrong with the previous configuration of the switch, since it affect to the booting and it was working like that in version 2014.2. Does anyone know why this happens?
Anyway I'm happy to have found the solution to this issue!
Regards,
Ignacio.