• Locked Locked
  • Replies 7 replies
  • Subscribers 54 subscribers
  • Views 4423 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Feature request: More friendly BKPT handling in ARM debugger

Robert Sprowson
Prodigy 70 points
Other Parts Discussed in Thread: AM3358

Hi,

I'm not sure where best to post ideas for Code Composer, so I'll try here.

In the ARM debugger when a software breakpoint (BKPT) instruction is hit the CPU halts as expected with the PC at the BKPT instruction and cursor at that line.

What would be more handy is if the single step button (green down arrow) stepped past the BKPT as though it were a NOP., and the run button similarly.

This makes sense because the debugger is already halted, and the next action is manually requested, and more closely follows what a hardware breakpoint does: step steps on by 1 instruction and run runs on.

At present, both single step and run on immediately halt the CPU again at the exact same BKPT and the only way to "escape" is by manually adjusting the program counter (PC) by 4 to move past it (unless I've missed something obvious).

 

 

  • TI__Guru**** 162885 points

    Robert,

    Let me try to reproduce this.

    Can you answer the following:

    • What device are you using?
    • What debug interface are you using? (XDS100, XDS200, ICDI...)
    • What version of CCS are you using?

    Regards,

    John

  • in reply to JohnS
    Prodigy 70 points

    CCS 5.5.0.00077 with XDS200 on a Cortex A series in ARM mode (not tried Thumb yet).

    You just need to run some assembler code with a BKPT in it, anything will do, something like

    MyFunction:

      MOV     r0, #42

      BKPT    123

      ADD     r0, r0, #42

      BX      lr

    and call that function. The debugger stops at the BKPT, but run on (F8) step in (Ctrl-Shift-F5) and step over (Ctrl-Shift-F6) are all resolutely stuck on the BKPT instruction, when it'd be much more useful if they carried on in a similar manner to how a hardware breakpoint works.

    Cheers,

    Robert.

     

      

  • in reply to Robert Sprowson
    TI__Guru**** 162885 points

    Thanks.  I have it reproduced now.  I think we might have a defect entry tracking better handling of breakpoints embedded in code.  I will see if I can find it and determine the status.

  • in reply to JohnS
    TI__Guru**** 162885 points

    Robert,

    If you use BKPT #123 instead of BKPT 123 it will work.  There is a bug in the way we interpret it.  I will file a defect to track it but you can work around the issue with #.

    Regards,

    John

  • in reply to JohnS
    Prodigy 70 points

    JohnS said:

    If you use BKPT #123 instead of BKPT 123 it will work.  

    Not here I'm afraid, and I don't think I'd expect it to as the '#' is merely an (optional) decorator for the assembler (see ARMv7AR manual DDI0406C page A8-345). In both cases I see the opcode in memory is 0xE120077B.

    The debugger ought to be looking at only the opcode in memory because it's quite common to not have source code correlation on a moderately complex system - for example because of run time generated code, or position independent code being loaded in after the debugger starts.

    Regards,

    Robert.

  • in reply to Robert Sprowson
    TI__Guru**** 162885 points

    Ok I think I know what is going on as it worked perfectly for me.  I just created a new project for AM3358 and selected the hello world template.  My project uses GCC so there was a startup assembly file included.  I just inserted the breakpoint instruction in the Enter_BootLoader function

    Enter_BootLoader:
    LDR r10,= _start @ Get the address of _start
    BKPT #0
    MOV lr,pc @ Dummy return
    BX r10 @ Branch to main
    SUB pc, pc, #0x08 @ looping

    It then halts at the breakpoint and I can step past it.  Same thing without the # is stuck.  I spoke with one of our debug interface engineers and they explained that essentially the breakpoint instruction is like this:

    BKPT #imm_value.

    The immediate value is embedded inside the opcode. In our driver we are testing breakpoint instructions to be BKPT with 0 as immediate value. We should instead mask the bits in the opcode that bear the immediate value and then test for BKPT instruction for embedded breakpoints.

    I believe it is working for me as at some point I have updated my "emupack" to a newer version (I was likely testing out a fix that was going into CCSv6).  I just tried this again on a more virgin version of 5.5 and I get stuck even with the #.  In my updated version and my CCSV6.0.0 install it works fine with #.

    Here are a couple captures from v6.

    I launch the debugger and it stops at the BKPT instruction

    I hit the green assembly step over button and it goes to the next line

    Is updating to CCSv6 an option for you?  I am not sure what type of license you have but since you are using an XDS200 I am guessing that it is a full license.  If your subscription is up to date you can just go to www.ti.com/myregisteredsoftware and select your license and then click the manage button and it will let you upgrade your license file to one that will work with CCSV6.

    I filed SDSCM00050124 to track the fact that it should work fine without the #.

    John

  • in reply to JohnS
    Prodigy 70 points

    The immediate value is embedded inside the opcode. In our driver we are testing breakpoint instructions to be BKPT with 0 as immediate value. We should instead mask the bits in the opcode that bear the immediate value and then test for BKPT instruction for embedded breakpoints.

    This seems to be the important bit - if I swap to using

      BKPT 0

    then it can be stepped over in CCS 5.5.0.00077 like my feature request asked, so it sounds like this should be logged as a fault instead since the debugger should mask out the immediate value when considering what to do.

    I often use non zero immediate values so I can leave several BKPTs in different code paths and know which one is which when they hit.

    Is updating to CCSv6 an option for you?

    I can do, though it doesn't sound from what you say that this will help with non zero immediate values which appears to be the trouble. I don't have a problem with '#' or no '#' (but agree that both should generate the same code and behave the same).