[SOLVED] Trace of function loaded to RAM.

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

  • [SOLVED] Trace of function loaded to RAM.

    My target processor is a Kinetis K64 which has an ETB. I am using trace with Ozone over SWD. At first I was getting Unknown Address in the trace listing and corrected this by adding Exec.Command("ReadIntoTraceCache 0x1FFF0000 0x40000") to AfterTargetDownload().

    A block of flash beginning with the function of interest is copied to RAM and that function is called using the appropriate pointer-to-function. The copied block is larger than the function of interest so additional, unused, instructions are copied to RAM as well.

    The immediate problem is that trace is suggesting that instructions AFTER the function are being called but, using a hardware breakpoint, the processor does not appear to hit these instructions.

    Below is a excerpt from the trace capture. I set two hardware breakpoints. The first is the return (pop of some registers and program counter) from the desired RAM function. This breakpoint works. When I examine the stack I can see that the proper return address will be copied to the PC and indeed it returns to the caller which is in flash. However, a breakpoint set after this never halts the processor.

    I'm dealing with a very nasty reset problem and believe a proper trace will help me debug this but I don't trust what trace is telling me. I certainly wouldn't expect code to execute past the POP instruction but then again if it is it might explain the issue.

    1FFF0E60 LDRB,"R0, [R3]"
    1FFF0E62 AND,"R0, R0, #0x31"
    1FFF0E64 MOVS,"R1, R6"
    1FFF0E66 POP,"{R3-R5, PC}" <---- HW Breakpoint Hit
    1FFF0E68 BLX,"R3"
    1FFF0E6A B,"0x0FFF0E58"
    1FFF0E6C SUB,"SP, SP, #0x08"
    1FFF0E6E MOVS,"R3, #0x00"
    1FFF0E70 STR,"R3, [SP, #0x04]"
    1FFF0E72 B,"0x0FFF0E6E"
    1FFF0E74 PUSH,"{R3-R7, LR}" <--- HW Breakpoint Ignored
  • Hello,

    Thank you for your inquiry.
    The issue is most likely related to calling ReadIntoTraceCache before Flash to RAM copy has finished. That way J-Link caches "garbage" instructions and tries to trace them with wrong information.
    Make sure to call ReadIntoTraceCache after all RAM changes have been finished and RAM is known to be valid.
    This is also described in our Wiki article to this topic: wiki.segger.com/Getting_unknow…sses_in_instruction_trace

    So what you can do is set a breakpoint at a point when the Flash to RAM copy is definitely finished. Then open J-Link commander and execute ReadIntoTraceCache.
    If you then continue your application you should get the correct trace stream.

    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.
  • These are not garbage instructions. They are the correct block copied from flash. I also tried an experiment where I only called ReadIntoTraceCache with the exact amount required for the function and got Unknown Addresses.
  • Hello,

    The important part is *when* do you call ReadIntoTraceCache.
    It is crucial that it is called after the memory area that should be cached is valid and does *not* change afterwards.
    If you call it before, Trace will be incomplete/incorrect.
    If the memory content changes after you have called it, Trace will be wrong as well.
    Did you make sure that neither of these cases appear in your setup?

    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.
  • I believe these conditions were satisfied during my last debugging session. I understand that in my original setup, where ReadIntoTraceCache is called in AfterTargetDownload, might have been a problem.

    Do you think you can describe how the debugger interacts with the ETM/ETB a little more deeply?

    When ReadIntoTraceCache is called does that build a map of addresses and the instructions in memory (at that time of course)? Then the ETM is configured to deliver only addresses to the ETB? The debugger then puts these two pieces of information together? When I look at the trace information can I trust that the addresses are always correct but that the instructions may not be depending on when that call to ReadIntoTraceCache is made?
  • Hello,

    I understand that in my original setup, where ReadIntoTraceCache is called in AfterTargetDownload, might have been a problem.

    This can be a problem if traced application content changes during runtime after the initial application download.

    When ReadIntoTraceCache is called does that build a map of addresses and the instructions in memory (at that time of course)? Then the ETM is configured to deliver only addresses to the ETB? The debugger then puts these two pieces of information together?

    ETM output is relatively "dumb" as the stream will only output at what address it currently is and how many instructions have been executed or not.
    To reconstruct instruction trace from that information the debug probe and analyzing software needs to know the application running in the target exactly.
    So as you wrote these two information are then put together.

    Usually the debug probe knows the application as it has just downloaded it onto the target, but in some cases e.g. preprogramed Bootloaders , attaching to a target, RAM execution etc. there are additional instruction pieces that the debug probe has no information about.
    That is what ReadIntoTraceCache is for. It will trigger a read from the target to get the current instruction information from the target to be able to reconstruct the instruction trace correctly.

    When I look at the trace information can I trust that the addresses are always correct but that the instructions may not be depending on when that call to ReadIntoTraceCache is made?

    This is correct.

    I hope the whole trace thematic is more clear now.

    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.
  • Re-reading my own post, there is the original question: Why didn't execution halt on the second hardware breakpoint? Especially if the trace addresses are reliable.

    I did eventually resolve this issue. Interrupt code was running in the same block during a program or erase of a sector in that same block. That's why a routine was copied to RAM. This is known problem with these processors but it is not well described in their application note.

    Maybe there is a hardware bug of some kind or a limitation of trace that I do not understand. Which to believe? The addresses from trace or that the breakpoint hardware failed?
  • Hello,

    Re-reading my own post, there is the original question: Why didn't execution halt on the second hardware breakpoint? Especially if the trace addresses are reliable.

    The trace addresses are reliable if the application does not change in the background. In your initial post you wrote that you saw instructions "after" your actual function where you the set the second BP on.
    I assume the code at that addresses changed after target download. So the debug probe does not have the current instruction information. The ETM will now tell the debug probe that e.g. 5 instructions were executed 2 not. If wrong instruction information is known to the debug probe instruction trace will show wrong addresses. At certain events e.g. branches ETM sends a sync packet with correct address information to resync the trace stream to the correct address again. But with wrong instruction information the addresses between syncs can be displayed wrong.
    This is a limitation by ETM to compress the trace stream, otherwise high speed trace would not be possible for targets over 100 MHz CPU speed.

    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.