[SOLVED] Unusual Code Profile / Trace Indication of Instruction Execution

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Unusual Code Profile / Trace Indication of Instruction Execution

    Hello,

    I'm new to Ozone and am working through a code coverage exercise on a project. I noticed what seems like conflicting indication of instruction execution between the Code Profile window and the source/disassembly window (see attachments). Based on my reading of the manual, the fetch/execution counts, and the green/orange execution profile color code it would seem to indicate that the instruction at 0x402432 is ALWAYS fetched and executed in the Source window, but the Code Profile window indicates 0% instruction coverage for the instruction that location. Is this a bug or am I misreading either (or both) the manual and what's being indicated?

    Thanks, in advance, for your help.
    Images

    • Code Profile.PNG

      11.03 kB, 829×105, viewed 294 times

    • Source Window.PNG

      15.8 kB, 503×230, viewed 399 times

  • Hi,

    Thank you for your inquiry.
    What target device are you tracing currently?
    Do you see this behaviour only on IT blocks or also with other conditional instructions e.g. conditional branches?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Nino,

    I'm using a Atmel/Microchip ATSAMV71Q21B with the Cortex-M J-Trace Pro.

    I'd have to check the other conditional branches, but I did check to see if there were other IT blocks with a similar behavior and I did find at least one more (see attachments).

    Thanks for your help.
    Images

    • Code Profile (part 2).PNG

      9.44 kB, 727×87, viewed 284 times

    • Source Window (part 2).PNG

      6.05 kB, 433×74, viewed 290 times

  • Nino,

    I checked around to other branching operations and it seems to happen in other compare/branching operations. See in the attached image where the Source Window seems to correctly indicate that execution has branched to 0x00400F08, and so does the Code Profiler with the exception of the branch instruction itself which it claims to not have executed.

    The same code and disassembly is shown in the Code Profile as in the Source window (and sorted in the same order this time).

    Thanks.
    Images

    • branch_snippet.PNG

      44.95 kB, 1,154×231, viewed 284 times

  • Hello,

    Thank you for clarification.
    The SAMV71 uses ETMv4 for tracing where support for conditional non branch instructions is "implementation defined" so currently this is not available for this target device. That is why the IT block evaluates incorrectly. But we will check if the target device supports this mode and it will be added to the J-Trace software then. Should it not be supported by the target we will check if the display of the code coverage can be improved.

    In case of the conditional branch sample with the BMI instruction, here everything is correct. The code coverage shows 0/1 so 0% of the instruction covered as the instruction is by definition only fully covered if both cases have been passed successfully.
    Right now the BMI instruction was only passed once with the condition being true, so the source counter is 1 and the coloring is green/yellow indicating that the true path has been taken but the untrue path not.

    More information about the coloring and statistics of the code coverage and code profiling you can find explained in the Ozone user manual.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Nino,

    Thanks for your response and the excellent explanation though I can see where saying the instruction coverage is "0/1" is counter-intuitive since it seems to imply that the instruction was not executed at all. The source counter indication of the split green/yellow makes perfect sense since both paths haven't been taken, but in the case of the instruction coverage I feel like you be would safe saying "1/1" since the instructions that follow (in the event that the branch occurred) still haven't been executed so there is no false indication that something has been run when it hasn't. However, I can see where, when a single instruction has multiple functions (evaluation and branching), that its probably safer to indicate that it wasn't fully executed than the other way around.

    Thanks again for your help.

    The post was edited 1 time, last by pdub ().