cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jrmclaurin
Visitor
Visitor
630 Views
Registered: ‎12-04-2019

Newly created Hello World project won't run on xc7z007s

Jump to solution

Last week I got our application to run and boot up on a custom board with an xc7z007s SOC. But I have been unable to create any new application projects that work--even the hello world example does not work.

I am able to create new FSBL projects that work fine from our hardware .xsa. The FSBL will run and print its debug output to the UART, where we can read it. But none of the application projects we create work at all.

Attached is a screenshot of us trying to run the application in the debugger. It seems to be stuck right at the reset location. An older application we have is able to run out of DRAM from a base address of 0x100000.

The hardware all works great, and an older project runs on the SOC, but for some reason any new project we create seems to have some fatal flaw. Any help would be greatly appreciated!

hello world app failure.png
0 Kudos
1 Solution

Accepted Solutions
jrmclaurin
Visitor
Visitor
420 Views
Registered: ‎12-04-2019

OK, I solved the issue... the wrong RAM device was configured in Vivado. During the process of bringing up our custom board, I actually did configure the right RAM device in Vivado, but I forgot to run the script that exports our BD to a TCL file. So when I cloned another copy of the project, the RAM settings were incorrect, and I went through a week of hell before figuring that out.

As I said in another post, Xilinx tools are designed in a way that's actively hostile to the proper use of source control. I've never used tools from any other vendor where using source control requires writing scripts that copy files back and forth between a source controlled directory and the actual project. It's insanity, and I hope someday Xilinx listens to their users and fixes this.

View solution in original post

0 Kudos
5 Replies
joancab
Teacher
Teacher
618 Views
Registered: ‎05-11-2015

 

"does not work", "won't run" are terribly ambiguous terms.

I would suggest refreshing the App's BSP, doing a "Clean all projects".

I use to boot from SD card, I heard from some people that could not boot software if the programmer (HS3, etc.) was attached.

jrmclaurin
Visitor
Visitor
603 Views
Registered: ‎12-04-2019

Thanks joancab for the reply.

I tried refreshing the BSP and doing a "clean all", and got the same result.

I've attached the XSCT output in case it's helpful.

Thanks again!

0 Kudos
joancab
Teacher
Teacher
590 Views
Registered: ‎05-11-2015

 

I suppose you have other boot media (QSPI, uSD). I'd try:

- flashing the QSPI with platform cable or whatever

- making a boot microSD

Obviously, set the boot jumpers accordingly.

I've been sometimes in that situation and is very embarrassing because the only thing you can say is "I don't know why".

With the above, if you get the sw running, at least you know it's not the sw itself but the boot media. If it does the same with any media, then I'd say something is broken in the sw.

0 Kudos
jrmclaurin
Visitor
Visitor
584 Views
Registered: ‎12-04-2019

Yeah, since I'm able to create working custom FSBLs, I'm able to program the QSPI and attempt to boot the app that way instead of running it from the IDE via the JTAG. Unfortunately it doesn't run in that case either. I do believe something is wrong with the ELF file, but I have pretty much nothing to go on other than that.

The board has a switch that lets us easily switch between JTAG and QSPI boot modes, which is handy. I've also been able to make a custom FSBL that lets us debug a QSPI boot sequence. The boot sequence all seems to be fine, including copying the app to RAM at the 0x100000 base address. The app binary seems to be where the issue is. Since this is just a hello world project, and we can prove that the hardware does work, I'm hoping I can get some support from Xilinx on this.

Thanks again!

0 Kudos
jrmclaurin
Visitor
Visitor
421 Views
Registered: ‎12-04-2019

OK, I solved the issue... the wrong RAM device was configured in Vivado. During the process of bringing up our custom board, I actually did configure the right RAM device in Vivado, but I forgot to run the script that exports our BD to a TCL file. So when I cloned another copy of the project, the RAM settings were incorrect, and I went through a week of hell before figuring that out.

As I said in another post, Xilinx tools are designed in a way that's actively hostile to the proper use of source control. I've never used tools from any other vendor where using source control requires writing scripts that copy files back and forth between a source controlled directory and the actual project. It's insanity, and I hope someday Xilinx listens to their users and fixes this.

View solution in original post

0 Kudos