Search Results

Hello JCP I used readelf --all app0.elf and found the following: There are no unwind sections in this file. So apparently your tool chain did not create unwind information. Without such information Ozone cannot do unwinding. I recommend persuading your tool chain to create that information, than Ozone should be able to operate as expected Best regards -- AlexD

Hi JCP, there are two reasons for this message being displayed in Ozone: 1. Data location of the return address is invalid. 2. Data location of the CFA (canonical frame address) is invalid. Root causes may be (among others) stack corruption or lack of debug information in the ELF file. Could you provide info on which eval board this can be reproduced? And which steps I need to perform in order to reproduce the issue? Best regards -- AlexD

Hi dev_alexz, right now there is no way to disable this dialog. Best regards -- AlexD

Hi JCP, Green Hills tool chain creates debug information that is proprietary and not conforming to standard formats. Green Hills also does not disclose documentation or information on that proprietary format. Therefore Ozone can only work with the fraction of debug information that is conforming, which limits the debug experience. Does that answer your question? Best regards -- AlexD

Hi gobo, the folder you are referring to was removed quite some time ago. There is now a central folder to be used. For details please refer to wiki.segger.com/J-Link_Device_…t_Kit#JLinkDevices_folder Cheers -- AlexD

Hi Zamniah, good to hear that you are up and running now. Best regards -- AlexD

Hi Zamniah, so the issue is gone now and you resolved it by disabling optimization in IAR EWARM? Best regards -- AlexD

Hi Zamniah, our first guess is that SPCmd::HandleCmdData() is inlined and ??HandleCmdData_## represent the locations where the inlining actually takes place. If so, the ELF file does not tell Ozone about that inlining, otherwise setting a BP on SPCmd::HandleCmdData() would have caused a BP being set onto each ??HandleCmdData_##. Our 2nd guess is that the code is optimized (but you stated that you disabled optimization). Another option might be that the tool chain created debug information in DWA…

Hi Adam, on which OS are you working? MacOS? Linux? 32 Bit? 64 Bit? Which OS version? Best regards -- AlexD

The issue is fixed with Ozone 3.28c.

We found an issue in the RTOS window handling which might have led to the described issues. We fixed the issue with Ozone 3.28c.

Ozone uses the J-Link for accessing the hardware and does not deploy its own memory access scheme. When populating the memory window Ozone asks J-Link to provide the content of the memory and displays the result. Maybe the SmartView feature is the tool of choice for your purpose: You might implement a SmartView plug-in which allows you to access the differential flash memory in the special way required for your purpose and display the contents in a table. The SmartView window is described in sec…

Hi Aritec and Xiaofeng.lei, it appears to be the case that Apple broke some compatibility in MacOS Ventura. We're investigating. Best regards -- AlexD

Hi Zamniah, as you can see in section 1.1 "What is Ozone?" of the Ozone user's manual, "Ozone is a source-level debugger for embedded software applications written in C/C++ [...]." Rust uses some encoding of the debug information for basic types inside the ELF file that is not compatible with C/C++. We already have adding support to those basic types to Ozone on our internal wish list for future improvements but cannot comment on when this will be available. Best regards -- AlexD

Hi pcpro178, Dark mode for Ozone is still on our internal wish list for future improvements but I cannot comment on when this will be available. Best regards -- AlexD

Hi Chrishock, I did a quick check with an embOS application and this worked well, in particular the Call stack is displayed correctly. Which RTOS plug-in did you use in 3.26i and which are you using in the 3.28? Does the issue persist with Ozone 3.28b? Best regards -- AlexD

Hi Przemek, such an issue is not know to us. Could you please file a ticket in our ticket system? Please note that for further analysis a reproducer is required which allows us to reproduce the issue locally. Best regards -- AlexD

Hi Adam, another option would be using the console window and issuing the command Break.SetOnSrc ("<function name>"); Which Ozone version do you use? I just checked with Ozone V3.28b on Windows 10 and found that [ctrl]-[alt]- works in quite a lot of windows, including "Source Files", "Break & Tracepoints", "Console", "Call Graph" and, of course, "Source viewer/editor". If the hot key is pressed in any of those windows, the Set/Clear Breakpoint dialog opens. Could you please double check on your …

In your Ozone project file (*.jdebug) there is a statement Project.SetOSPlugin ("<filename>"); Here you need to replace <filename> with the corresponding RTOS awareness script. For FreeRTOS there are multiple flavors provided with Ozone, you can find them in the installation directory, e.g. C:\Program Files\SEGGER\Ozone V3.28a\Plugins\OS. Please pick the one that fits your core. You may wish to have a look at section 7.9.14.10 in the Ozone User's Manual where the Project.SetOSPlugin() command in…

Hi Oliverb, which RTOS are you using and which RTOS awareness plug-in? Please note that in the older Ozone versions there was a DLL interface for RTOS plug-ins which was discontinued quite a while ago and removed from Ozone in version 3.28. Instead, the JavaScript plug-in interface is being used. In section 6.3 of the Ozone user's manual you find a documentation of the plug-in I/F. Best regards AlexD