cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sktpin
Adventurer
Adventurer
395 Views
Registered: ‎09-11-2018

MicroBlaze / SDK - Debugger does not halt on main(), but somewhere deep in the code

I am using Xilinx SDK 2018.3 with an Artix7.
My Microblaze program priviously worked, and debugging worked fine.

Not anymore.

I added code that, next to SPI0 in normal SPI mode as slave, now also uses SPI1 as a master in QSPI mode.
The program got too big (with debug symbols), so the MicroBlaze memory was increased from 64KB to 128KB.

The target hardware has the new FPGA config inside, and I copied the new .hdf file to the Microblaze project - the SDK noticed.
I "re-generate BSP sources" & rebuilt the bsp project. I re-generated the linker file and re-built the main project.

Now if I start debugging, the Breakpoints window shows "funciton: _exit" and "function: main", and I even added a breakpoint to some advanced line in main() myself.
But when debugging starts, it does not halt in main.
The SDK shows me, as the supposed code file & line that it's at, the end of some function deep in the call hierarchy.
And in the callstack, it shows another function & line one call before the function where it halts 9 times repeated (exactly same line).
This doesn't make sense, the code does not work that way. The topmost function on the callstack which the debugger halts at when starting debugging, does *not* get called from there, and the supposedly calling function is even warned by the compiler to be unused... the list of items in the callstack doesn't make sense.

Edit:
I change the debug config to "halt at program entry", now the call stack is not filled with all those repetitions, only one entry - but still it's at a fucntion which is not used by the program (hence the compiler warning about unused static...)

So what I'm seeing is not real, the debugger is showing nonsense.

How can I find out what's going on? Are there typical causes for something weird like this happening?

0 Kudos
Reply
2 Replies
sktpin
Adventurer
Adventurer
335 Views
Registered: ‎09-11-2018

So I went back to a previous .hdf, and microblaze project, version, and also coldn't debug properly, the SDK debugger would show crazy call stacks and variable contents.

At some point, it seemed to land in a X...Transfer function and there in Xil_Assert. I wanted to know why, and set the BSP option to compile with -O0 (instead of the -O2 default). Alas, the n ewly built main project then got too big to fit in the memory.
I set it back to -O2 and rebuilt all.

And then, at least the older version of my microblaze project worked again (the one without the 2nd SPI and with the smaller µBlaze size).

I struggled for a day to get that running again, and now, by some miracle, it does.
Without any changes to any of the code, mind you.
And I had the X SDK IDE regenerate + rebuild the BSP, and rebuild the application project several times without getting it to work normally again afterwards.

Is there a document somewhere which describes what exactly needs to be done when in the Xilinx SDK IDE, to not be sent on such goose chases?
This all seems rather intransparent, no indication in the IDE that something is wrong, let alone what. This is a huge resource burner.

0 Kudos
Reply
sktpin
Adventurer
Adventurer
318 Views
Registered: ‎09-11-2018

The newer versions of .hdf / bitstream and the MicroBlaze firmware still don't work together, though.
After debugging starts, it does not halt in main. But I can "Suspend" the application, and then the current instruction, ina dissassembly, is shown, to be "add r0,r0,r0", in a row of repeated instructions exactly like that - so that's probably not real.

I noticed a difference in the linker script that resulted from the older .hdf vs. the cuirrent version, with the bigger memory for the MicroBlaze.
Not just the expected bigger numbers for memory, but not there are two instead of one regions defined.
What exactly does that mean? Does that hint at an error in configuration somewhere already?

(old)
MEMORY
{
   microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem : ORIGIN = 0x50, LENGTH = 0xFFB0
}

---------------------------------------------
(new, bigger memory for µBlaze)
(why 2 regions defined instead of one?)
MEMORY
{
   microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem : ORIGIN = 0x50, LENGTH = 0x1FFB0
   microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem : ORIGIN = 0x80000000, LENGTH = 0x20000
}
0 Kudos
Reply