Search Results

Hi Ekengr, please open a support ticket against J-Link in our ticket system. For doing so, please follow the link in my the footer of my post. Best regards -- AlexD

2. I've added that idea to our internal wish list for future improvements. 11. I was still not able to reproduce the issue. I could not find any graph jumping when moving the mouse after zooming via the mouse wheel. It appears to be the case that even in your environment this is not always reproducible. Once you are able to provide a stable reproducer please share that with us.

Hi DavidHC_96, are you able to reproduce the issue with the current release of Ozone, V3.28c? As you describe the issue it might just be the case that your target, once being unleashed, simply runs into a condition that triggers a restart. Eventually you application leaves the code range covered by your break points within the blink of an eye and then restarts. Your system might also simply make use of a watchdog which, after some time, triggers a reset. Of course, this is pure guesswork. With t…

Hi JCP, thanks for coming back to us and glad to see that you are now able to proceed in your work using Ozone. We are not planning to implement such a disassembly based stack unwinding feature. Providing the unwinding information as DWARF information in the ELF file is default for virtually all development tools, GHS being the rare exception. You may contact GHS support and ask for providing that information in a more standardized fashion, though. Best regards -- AlexD

Hi Julian, thank you for your suggestion. I added that to our internal wish-list for future enhancements. Best regards -- AlexD

1. We do not see added value in such a start/stop button. Therefore the feature will not be implemented. 7. The web site for the J-Link Plus (segger.com/products/debug-probes/j-link/models/j-link-plus/) contains a section that advertises that Ozone can be used with that device. This section also contains a small excerpt of Ozone's overall functionality, which includes power graph and instruction trace. Ozone does support all those features, but only with the J-Links that do support them as well.…

Hi Blunce, let me summarize what I took from your description: Ozone is connected to the target, target is running, watched data window is open and populated with a few variables, refresh rate is set to a value other than "Off". Ozone reflects the changes in those variables but sometimes a strange value is displayed which does not fit to the expected values. You see this only under the condition that Ozone connects to the target after the boot loader has executed. If Ozone connects in your delay…

Hi JCP, at first glance I see Warning (107): The program file does not contain DWARF debug information. So apparently your ELF file does not contain debug information. Such debug information is required for stack unwinding. So could you please check if you can create an ELF file which actually contains debug information? Best regards -- AlexD

Hi Fraengers, 7. J-Link EDU does not support the power profiling. This is the feature a J-Link needs to possess in order to work with Ozone's power sampling window. For that a J-Link ultra plus or better is required. I assume that this leads to your power sampling window not being populated with power measurements. If the list is empty the window does not offer scrolling. This would also explain why you do not see the power plot in the Timeline window: No data - nothing to graph. 8. This is inte…

Hi JCP, unfortunately we do not have the eval board you described on stock. since the application is quite simple, can you reproduce that behavior on a different evaluation board or hardware platform? Could you provide an Ozone log you recorded during your debug session? How to create an Ozone log is described in section 8 of the Ozone user's manual. Best regards -- AlexD

Hi JulianR, in case this phenomenon re-appears, feel free to contact us again. Best regards -- AlexD

Hi Blunce, to me the intention of your post is still a bit unclear. Could you please elaborate on what you do, what behavior you expect to see, what behavior you do actually see and where you are looking? Best regards -- AlexD

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…