Difference between revisions of "Ozone detects wrong application entry point"

From SEGGER Wiki
Jump to: navigation, search
Line 4: Line 4:
 
</pre>
 
</pre>
 
This function will return the entry point of the elf file. However for some available toolchains this entry point address will not be the actual address from where the target application starts but rather the point where the C runtime library starts executing. Depending on your target application this might lead to issues as he SystemInit might be skipped that way.
 
This function will return the entry point of the elf file. However for some available toolchains this entry point address will not be the actual address from where the target application starts but rather the point where the C runtime library starts executing. Depending on your target application this might lead to issues as he SystemInit might be skipped that way.
While this behaviour of the toolchains is technically not wrong it makes not much sense for most embedded target devices.
+
While this behaviour of the third party toolchains is technically not wrong it makes not much sense for most embedded target devices.
   
 
Anyhow should you run into this issue it can simply be fixed by replacing the line mentioned above with the following instead:
 
Anyhow should you run into this issue it can simply be fixed by replacing the line mentioned above with the following instead:

Revision as of 14:05, 14 July 2020

When autogenerating a project with Ozone V3.20 or later you will find the following line twice in the Ozone .jdebug project file:

PC = Elf.GetEntryPointPC();    

This function will return the entry point of the elf file. However for some available toolchains this entry point address will not be the actual address from where the target application starts but rather the point where the C runtime library starts executing. Depending on your target application this might lead to issues as he SystemInit might be skipped that way. While this behaviour of the third party toolchains is technically not wrong it makes not much sense for most embedded target devices.

Anyhow should you run into this issue it can simply be fixed by replacing the line mentioned above with the following instead:

PC = Target.ReadU32(VectorTableAddr + 4);  

Now everything should be working as expected.

Should this also fail check if the VectorTableAddr detected by Ozone is at the expected address. If not either the debug information in the elf file is missing/incorrect or you are debugging a multi image setup. To solve the precedent error simply set the VectorTableAddr to the expected value. For the latter issue see the following Wiki article: https://wiki.segger.com/Debug_on_a_Target_with_Bootloader