Search Results

Hi Hudson, there are 2 things participating in your scenarios: 1) The ELF file 2) The Ozone project file If the Ozone project file is exactly the same in both your projects for IAR and GreenHill, then the root cause must be sought in the ELF file. It may be possible that IAR is lacking some information that must be reported to Ozone via the Ozone project file. Since you state that you are targeting a system with boot loader, some special considerations must be done, which are described in this k…

Hi OzoneDarkThemeWhen, having a dark theme for Ozone is already on our internal wish-list, but at this point in time I cannot comment on when this feature will be released. Best regards -- Alexander Dexel

Hi ram.techen, thank you for the additional information. We will see if we can reproduce that locally. Since all our engineers are busy these days this might take some time. We will keep you posted here. Best regards -- AlexD

Hi ram.techen, Sorry, but this is not helpful here. You are providing logs from 2 different firmware versions. As stated before, due to a different firmware a completely different runtime behavior may be expected. If I got you right, you do have a firmware which at the beginning shows fast stepping but after some time switches to slow stepping. Please do a single debug session where both scenarios, slow stepping and fast stepping are reproduced and record J-Link log and Ozone log with that very …

Hi ram.techen, from the given information hardly anything can be said. You change the source code and a smart compiler might make a completely different assembly code from that. So a completely different runtime experience might be expected. Since you are able to reproduce the issue in your 1st bare metal program, could you please provide a J-Link log and an Ozone log recorded during the same debug session where you observe the slowdown? The logs should show both the fast execution and also the …

Hi balance3164, this information might be useful for other customers looking for a particular SVD file. Thank you for sharing it here. We might consider it, once we go for implementing the item on our wish list. Best regards -- AlexD

Hi balance3164, a similar feature is already on our internal wish list, but at this point in time I cannot comment on when it will be made available. For the time being please contact the silicon vendor of your device for that information. For the core registers Ozone provides suitable SVD files and they are selected automatically if you use the new project wizard. Of course, the peripherals are not covered. Best regards -- AlexD

Hi balance3164, good to hear you are up and running again. Concerning your 2nd inquiry: Ozone does not (yet) support the full scale of Rust features. What would be the type of `dp`? Best regards -- AlexD

Hi balance3164, Per default `rustup` will install libraries only in pre-built form. I assume that this is why you see only a part of the sources. So you need to make available the sources for the libs as well. For that you may try the following command:`rustup component add rust-src` With the following command you may find the path of your rust toolchain:`rustc --print sysroot` There under `\lib\rustlib\src\rust` you may be able to find the source then. To reference the sources to your Ozone deb…

Hi ram.techen, from the logs I cannot see what you are describing. In particular I looked into the `JLINK_Step` commands and found that they consume quite the same time in both slow and fast case. The command execution time is 4.836ms vs 4.718ms 4.501ms vs 4.588ms 4.676ms vs 4.796ms 4.573ms vs 4.423ms 4.929ms vs 4.819ms 5.093ms vs 4.610ms 4.761ms vs 4.816ms 4.724ms vs 4.524ms 4.752ms vs 4.574ms 4.596ms vs 4.581ms So in both cases you should experience a delay of ~5 seconds when stepping. Best re…

Hi OroArmor, Ozone does not change registers on its own behalf. It does so only if told by the user, e.g. in the context of the Ozone project file. Could you please provide a J-Link log and an Ozone log of the bad case where you see the incorrect value for R2 being displayed in the registers window? Creating a J-Link log is described here: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File and creating an Ozone log is described in section 8 of the Ozone user's manual. Looking into the project you…

Hi oskar, did you enable SWO capturing in Ozone's terminal window? Best regards -- AlexD

Hi Torsten, there is a horizontal scrollbar for the whole window, and in addition it is possible to freely change the column width. Having a scrollbar on a per-column basis is not planned. Best regards -- AlexD

Hi dirk.gehring, did you read the section 5.9 in the user's manual? Did you set all fields accordingly? Does your hardware support data break points? If so, could you please provide a J-Link log as well as an Ozone log recorded during the same session where you reproduced the issue? Creating an Ozone log is described in section 8 of the user's manual, creating a J-Link log is described here: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File Best regards -- AlexD

Hi Kayers, it appears to be the case that your reproducer does not reproduce the issue seen in your original post. In your original post I see multiple source lines, stated as source file name and line number, being mapped to the same disassembly line. At least in your screenshot I cannot see this. All I can see here is a single source file, without a line number information, being matched with an address in the disassembly, and a few symbols being oddly mapped into the disassembly. This appears…

Hi kayers, splendid. As often: The smaller and simpler, the better - so feel free to reduce to the max Best regards -- AlexD

Hi Kayers, Ozone relies on the information found in the ELF file, which also contains information on the mapping of source code to addresses and vice versa. The ELF file contains such information in a highly compressed and rather complex format and it might be that you found a spot where Ozone does not properly interpret the information. Could you please share your project with us, so we can have a closer look? If you do not wish to publicly share your project in this forum, feel free to open a …

Hi AndersHedberg, if an RTOS plug-in is lacking some feature you can easily add this on your own. For details please refer to the Ozone user's manual, section 6.3. You may also look into the scripts provided for other RTOSes and if the desired information is made available there, you might take that code part as a template for adding the same information for your application. If you intend displaying information encoded in your firmware in a human readable form, the SmartView feature in Ozone mi…

Hi Aleksei, I need to admit I do not yet fully grasp what you intend doing. Therefore, at this point in time, I can provide just some general thoughts. It appears to me that you intend changing the execution address range of your application so it differs from the place that is specified in the ELF file. In that case you need to tell Ozone where to find code by invoking `Debug.ReadIntoInstCache()`. It appears to be the case that this is not yet done in your setup. For details please refer to sec…

Hi Simon884, good to see that you are now able to see your RTOS tasks. For the others it might be valuable if you'd describe what you did to make the tasks visible. Normally Ozone should do that out of the box, so I assume that you simply looked into the window at a time where no RTOS task was started yet (e.g. directly after reaching main() function) and the window filled with content once you looked into your firmware at a later execution stage. The run counters are a trace feature. You need t…