Posts by SEGGER - AlexD

Hi sckare,
thanks for your inquiry. We are not aware of such flaws in Ozone, but, unfortunately, from your description we cannot see what exactly is not working from your perspective. So could you please provide reproducers on eval boards, allowing us to reproduce the issues? We'd need the Ozone project file, the ELF file and all sources required for reproducing the issue. We also need a detailed description on what steps to perform in order to reproduce the issue. Please also describe what you see and why you think that this is wrong.
In case there are multiple issues, feel free to provide multiple reproducers.
Best regards
-- AlexD

Hi dellis-innoflight,
short answer: Such features are neither available nor planned to be implemented.
When it comes to having a better insight into the internals of your application you may wish to have a look at the SmartView feature offered by Ozone. Please refer to the user's manual, sections 4.15 and 6.4.
Best regards
-- AlexD

Hi penjuin,
we work on improving the handling of FreeRTOS scripts in Ozone, but at the moment we do not plan to add new RTOS plugins. The plugin for Cortex M4/M7 should work for Cortex-M33 as well.
Please refer to the Ozone user's manual: In section 6.3. you will find a description on how to create your own RTOS plugin. You may take one for the existing plugins as a starting point.
Best regards
-- AlexD

Hi Martin,
glad to see you are up and running again.
Happy debugging and best regards
-- AlexD

Hi scal8,
good to see you are up and running again.
Best regards
-- AlexD

Hi Martin,
please have a look at https://kb.segger.com/Raspberry_Pi_RP2040. There it is stated

Quote

"the RP2040 includes a boot ROM which needs to be executed after reset in order to guarantee proper functionality."

Please check if the knowledge base article I referred to earlier does help you here.
Best regards
-- AlexD

Hi Andy,
thanks for the details. Might well be that Ozone gets a hick-up when handling file names as you did. We will check if we can reproduce that locally. Stay tuned, we will report back.
Best regards
-- AlexD

Hi andypandy,

thank you for the flowers and good to see you are up and running again.

Actually, Ozone should be able to cope with ELF files not coming with a file name extension. In that case ELF file detection is supposed to operate on the ELF file header information, which, according to your initial post, appears to be OK. So if you could provide your ELF file we could check if we can reproduce your observation.

Best regards
-- AlexD

Hi enz,
it appears to be the case that your Ozone project is not set-up correctly. If your Ozone project replicates your ES environment correctly, you will be able to debug your application with Ozone as well. I cannot tell where the issue lies. You may check our knowledge base for ideas. Assuming that your system uses a boot loader, you may check out this article: https://kb.segger.com/Debug_on_a_Target_with_Bootloader
Best regards
-- AlexD

Hi scal8,

if you want to be quite exact, SystemView is your solution. In SystemView upon every monitored event a time stamp is generated.

When using instruction trace, however, a time stamp is generated only every now and then. Ozone cannot do better than interpolate between two time stamps based on the instructions executed in the meantime. You may adjust the frequency at which the trace unit generates time stamps. For details on this please refer to this article in our knowledge base: https://kb.segger.com/J-Link_Command…leITMTimestamps. Maybe this improves your measurements to an acceptable level. Please note that the time stamps share the same very limited bandwidth used for instruction tracing, so the additional load might lead to data loss and therefore gaps in your trace.

When it comes to measuring execution time of a function you may also wish to export the instruction trace window and do some post processing based on that file. If you know the addresses of the entry point and the exit point(s) of a function you may search for those addresses in the trace and based on the time stamp information calculate the time spent in-between.

Best regards
-- AlexD

Hi andypandy,
in general loading an ELF file should work as you expect it. According to the given information the ELF file should be digestible by Ozone. You may check if changing the file extension to ".elf" does have a positive effect. If not, could you please share your ELF file with us for further analysis?
Best regards
-- AlexD

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 knowledge base article: https://kb.segger.com/Debug_on_a_Target_with_Bootloader. Could you please have a look and check if everything is set-up as described there?

Best regards
-- AlexD

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 debug session. Please also provide the ELF file you were using in that very debug session.
Can you do that?
Best regards
-- AlexD

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 slow execution.
Best regards
-- AlexD

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 debug project you can simply use the `Project.AddPathSubstitute()` command.
Please note that we do not support the rust build tool chain. It might well be that the commands above do not work for you.
Best regards
-- AlexD