Ozone issues when running from flash address 0x00000000

kayers · Jan 16th 2025, 10:41pm

I am working with the TMS570LC4357 and we are running our code from flash address 0x00000000 where the application starts just after the vector table. When doing this, Ozone seems to be somehow overlapping a bunch of debug symbols, and when stepping through code it will just end up at random unrelated lines of code. The disassembly seen in figure 1 shows this behavior, where the blacked out source files are various different files which should not be correlated with this address. We found a "fix" for this, which is simply to push the start of the app back with some offset. This "fix" can be seen in figure 2. I am just curious if anyone has a better idea of what could be going on here, and if there is a better solution for it.

Figure 1: Disassembly in Ozone with overlapping symbols, when running with the app just after the vector table around address 0x00000000

Figure 2: The "fix" we made to our linker script which causes Ozone to work properly. The offset between the vector table and the app entry was added.

Also for what it is worth, the same code can be debugged perfectly fine with GDB

SEGGER - AlexD · Jan 17th 2025, 8:47am

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 ticket in our support ticket system. We'd require your Ozone project file and your ELF file, plus the information which of the source files displayed at address 0x00 are expected to be there and which are not. Does that work for you?
Best regards
-- AlexD

kayers · Jan 17th 2025, 9:06pm

Hi, thanks for the reply. I cannot share this project at all, but we will try to create a smaller example project which demonstrates the same behavior and post it sometime next week.

SEGGER - AlexD · Jan 20th 2025, 8:16am

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

Best regards
-- AlexD

kayers · Jan 21st 2025, 6:29pm

Here is a sample project (attached) quickly made with the SEGGER Embedded Studio, where a few source/header files were added to contribute to the debug symbols, and similar behavior can be seen in the disassembly:

SEGGER - AlexD · Jan 22nd 2025, 9:32am

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 to be a bit quirky as well, but this might be a completely different case from what you initially reported. If we look into this reproducer we may put effort into a topic which does not really solve your actual problem. We shall avoid that. Are you able to provide a reproducer showing what you see in your initial post?
Best regards
-- AlexD

Share