UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
9,952 Views
Registered: ‎11-24-2013

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

Jump to solution

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.

Tags (4)
0 Kudos
1 Solution

Accepted Solutions
Explorer
Explorer
17,445 Views
Registered: ‎11-24-2013

Re: Unable to load and run program in DDR from SDK

Jump to solution

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.

Tags (4)
2 Replies
Xilinx Employee
Xilinx Employee
9,932 Views
Registered: ‎08-02-2011

Re: Unable to load and run program in DDR from SDK

Jump to solution
Hello Ignacio,

Are you able to step through at all with the debugger to see if it gets stuck somewhere in particular?

As a test of DDR setup itself, what happens if you link to OCM but do some pointer access directly to DDR (maybe write 0xdeadbeef to 0x10000000, readback 0x10000000, then print it)? Does it work okay?
www.xilinx.com
0 Kudos
Explorer
Explorer
17,446 Views
Registered: ‎11-24-2013

Re: Unable to load and run program in DDR from SDK

Jump to solution

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.

Tags (4)