[SOLVED]Ozone warnings and unexpected code jumps.

Akito · Oct 4th 2022, 3:11pm

Hello,

When debugging a specific build, i have a yellow warning symbol in front of some lines of code, see image attached.

When i hover over the symbol, i get the following message: "Value may be incorrect: runtime code areas (RAM) not yet initialized." What does this message mean?

This also seems to cause unexpected code jumps into unreleated code sections when stepping through the code line by line.

Do you have an idea of what is going on?

Thanks.

mwb1100 · Oct 6th 2022, 6:11pm

I don't know about the message but unexpected code jumps (and other debugger weirdness) is often caused by debugging optimized builds, where the generated code doesn't line up with the source code because of the transformations the optimizer performs.

Make sure you are debugging a build that has optimizations turned off.

SEGGER - Nino · Oct 10th 2022, 9:33am

Hello,

Thank you for your inquiry.
As the poster before me mentioned one reason is typically a optimized build being debugged.
Make sure you have code optimization off and debug symbols active in your toolchain.

Another hint is the warning sign in your screenshot.
This usually indicates code that is generated on run time e.g. RAM code. Make sure that such areas are added to the instruction cache:
wiki.segger.com/Ozone_Debug_and_Trace_with_RAM_Functions

Best regards,
Nino

Akito · Oct 12th 2022, 11:20am

Hello,

Thank you all for your responses.

This issue is not related to typical code jump in debugging due to optimization. In addition, the code concerned with this issue is not generated on RAM code.
I have identified what seems to be causing this issue but i can't explain it.
The application uses a module which contains unused functions. The unused functions are marked to be located in the address 0x0 in the map file for unused components. When i link the application at address 0x0, the unused functions are marked as executable code in Ozone and i have the warning mentionned earlier on them. It is as if Ozone is confused on the possible location of these unused functions since Ozone indicates that they are located on address that contains start up code.

When i link the application in an other address like 0x00088800, everything beahaves nominally. Ozone correctly see that unused fonctions are not exectuable code and there are no warnings and jumps.

I suspect that it is an issue related to Ozone since the application linked at 0x0 behaves correctly with no jump or warning when debugging with Eclipse.

I also want to mentionned that the software linked at 0x0 is executed correctly, the jumps doesn't seems to be code execution jumps, more like debugger confusion.

What do you think about this?

Thanks.

SEGGER - Nino · Oct 14th 2022, 9:37am

Hello,

Akito wrote:

When i link the application at address 0x0, the unused functions are marked as executable code in Ozone and i have the warning mentionned earlier on them. It is as if Ozone is confused on the possible location of these unused functions since Ozone indicates that they are located on address that contains start up code.

This is not confusion. Ozone simply displays what you configure in your elf file. This is correct behaviour. If what you configure is wrong, Ozone will correctly show a warning to remind you about it.
What is the point of having a unused function section which you place over already existing execution areas?

Akito wrote:

I suspect that it is an issue related to Ozone since the application linked at 0x0 behaves correctly with no jump or warning when debugging with Eclipse.

Not really. Eclipse just has 0 intelligence to detect something like this. It is simply an incorrect elf file that is provided to the debugger.
Does not really speak for Eclipse allowing such constructs.

Any normal toolchain would optimize away unused functions as there is no point in having them.

Best regards,
Nino

Akito · Oct 17th 2022, 5:25pm

SEGGER - Nino wrote:

This is not confusion. Ozone simply displays what you configure in your elf file. This is correct behaviour. If what you configure is wrong, Ozone will correctly show a warning to remind you about it.
What is the point of having a unused function section which you place over already existing execution areas?

There are no unused functions placed over already existing execution areas. However, this is what Ozone is showing and telling me. This is confirmed by the map file and the fact that the code executes correcly. I am wondering then what in the ELF file is making Ozone behaves like this.

Thanks.

SEGGER - AlexD · Oct 18th 2022, 10:42am

Akito wrote:

There are no unused functions placed over already existing execution areas. However, this is what Ozone is showing and telling me. This is confirmed by the map file and the fact that the code executes correcly. I am wondering then what in the ELF file is making Ozone behaves like this.
Thanks.

You stated earlier "The unused functions are marked to be located in the address 0x0 in the map file for unused components." So apparently your tool chain does not optimize away unused functions and your linker script told the linker to link those unused functions to address 0x0.
Ozone finds that section in the ELF file and from it's attributes deducts that this is RAM code.
If you modify your linker script such that the unused functions are located in a different place, e.g. together with productive code, the section at address 0x0 will vanish. However, the unused functions still consume space, but this time in the section of the productive code. Since this section has attributes not indicating RAM code, Ozone treats them like "normal" functions, just as it does for the other productive code in that section.
If the code located at address 0x0 is unused it does not affect code execution. In general it is to be expected that the productive code executes correctly, no matter where the unused code is located.
Locating unused code in the memory rather than discarding it does not cause the unexpected code jumps you observe during debugging productive code. However, having productive code in uninitialized RAM may have such an effect. If you do a step on the target code the target will reach a new PC. Ozone will use the information in the ELF file for identifying the source location for that address and then display that source. If your source code contains a linear instruction but the memory contains a function call, you will end up inside the called function and not, as you'd expect, on the next source line. This happens regularly if the binary present in the target's memory does not match the ELF file. In case of improperly initialized RAM code you may find zeros or random data (which would be good since executing such instruction usually quickly results in an abort), but you may also find an image of a previous version of your application, and under such circumstances it is likely to observe unexpected jumps.
Did that answer your question?

Akito · Oct 20th 2022, 6:48pm

Thanks for the detailled response. I double checked and none of the 2 points (unused function linked at 0x0 and productive code in RAM) are occuring in my project. I will monitor this in future projects to see if it is still appearing.

Share