Search Results

Hello Alex, My apologies, when I switched that example project over to the gcc compiler I ensured the optimization level was set to debug (-Og) but neglected to add the -g option to generate debug symbols. After adding this, the call stack does work properly in Ozone. That brings me back to the original problem of why this is not working with the GHS compiler. While it is able to generate DWARF2 compatible debug information, I do not think this includes the call stack. After going back and re-ex…

Hello Alex, Please find the attached Ozone log. I looked through it, and the part that may be interesting is: Invalid BP data location for function main. Falling back to SP I'm not sure what that might mean or how to fix it though. The stack pointer it lists in the call stack does seem correct, so it seems like it could unwind successfully. I have reproduced this on multiple instances of hardware, but all were using the XA7020 chip. We do use JLink + Ozone on completely different hardware platfo…

Hello Alex, Thanks for the suggestion. I've tried adding the unwind section by specifying the -funwind-tables to the compiler options, and adding a .ARM.exidx section to the linker script. This appears to have worked correctly, as running readelf --all app0.elf now includes the following: Unwind section '.ARM.exidx' at offset 0x232f0 contains 32 entries: 0x100508 <test_func>: 0x80b0b0b0 Compact model index: 0 0xb0 finish 0xb0 finish 0xb0 finish Unfortunately, I'm still seeing the same behavior i…

Hello Alex, I re-built the example application using gcc (arm-xilinx-eabi gcc version 4.9.2 (Sourcery CodeBench Lite 2015.05-16)) and I still see the same behavior with the call stack. Please find the updated example attached. Reproducing this issue is as simple as flashing the target hardware (either externally in flash, or using J-Link to write the application to RAM), and then starting a debug session. As you set breakpoints or step through the code, the call stack window will only show the f…

Hello Alex, Thanks for the reply! GreenHills does have a proprietary format, but they also support an option to export the normal DRAWF2 symbols, which is what I'm using to debug with Ozone. So far most of the functionality works, so I can set and hit breakpoints, step through the code, and view variable values. The main issue I'm having is with the call stack, and since someone else experienced the same issue while using gcc I don't know that it is solely related to GHS. If you might have a cha…

I'm experiencing the same issue documented here: forum.segger.com/index.php/Thr…nding-symbols-at-address/ The call stack only displays the current function, and underneath shows the text: Top of stack - no unwinding of symbols at <address> Debug probe: J-Link Plus v10.1 18 - 46 Ozone V3.28b Target: Xilinx Zynq7000 series (XA7Z020) Compiler: GreenHills GHS ARM 2020.1.4 Please find the attached example project which can be used to replicate the issue.