This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Trace "timeline" doesn't make sense

I am working on customizing the DFU bootloader (to add encryption). When attempting to use the instruction trace in Ozone to debug, I see a lot of nonsense. One example is shown below. It is obviously in a loop (evidenced by the repeated cycle of function names), but they show up in the Timeline as nested functions. There seem to be periods of trace missing (shown as "<unknown>"), during which the instruction address jumps around seemingly randomly. Presumably the missing return's are in these areas.

My current hypothesis is that the SoftDevice disables tracing when execution is in it, which has the side effect of instructions being lost for some period of time before and/or after execution is in the SoftDevice.

Is this true? I don't care about tracing within the SoftDevice, but is there any way to get a more complete trace outside the SoftDevice?

  • Hi,

     

    My current hypothesis is that the SoftDevice disables tracing when execution is in it, which has the side effect of instructions being lost for some period of time before and/or after execution is in the SoftDevice.

    Is this true? Is there any way to get a more complete trace?

    The softdevice doesn't disable tracing, its just that your trace debugger does not have the debug symbols to resolve the softdevice functions.

    We distribute the softdevice as a binary, so its not possible to debug the functions at the level that you're requesting. All calls to the softdevice address area will come up as "unknown".

     

    Kind regards,

    Håkon 

  • I am not requesting to be able to trace within the SoftDevice. I only want accurate tracing outside the SoftDevice. (I don't care about the trace in the SoftDevice, but it might be a clue to you that the instruction address there jumps around randomly every instruction.)

  • Do you have any update on my question? Right now the trace is so corrupt that it is mostly worthless. Is that the answer: trace is unusable on a system that has a SoftDevice running? Breakpoints are already mostly unusable because the SoftDevice has a timeout that asserts when I hit a breakpoint, so I'm feeling like my hands are tied. I guess I will try good-old printf's.

  • Hi,

     

    Debugging only controls the CPU itself, while the peripherals still run.

    Unfortunately, you cannot break/go with the softdevice enabled, as this will make all events occur at the same time, and the softdevice finds that an event has occurred out-of-order, and it asserts.

     

    Kind regards,

    Håkon

  • Hello,

    I am experiencing the same matter. I want to trace my application and validate it by viewing Ozone's Timeline. However the readings do not make any sense. My view is similar to the one of . How can I resolve this? Do we have any other updates in the question?

    To clarify, I do not want to trace the softdevice calls that are currently shown as unknown. But I want a clear view of the rest of the application. I do not need to set breakpoint and then continue. My intention is to stop the execution at a specific point and view the Ozone's timeline.

    Thank you in advance,

    Aris.

Related