We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Visitor pexu
Registered: ‎01-08-2016

SDK 2015.4, System Debugger does not always restore original opcode for planted breakpoints



It seems that when using the System Debugger it doesn't properly remove the planted BKPT instruction for non-hardware breakpoints thus making any read operation on a breakpoint location effectively fail as opcode for BKPT (0xe1200070) is returned instead of the original data -- regardless if the execution first passes thru the breakpoint location.


Internet tells me that this isn't exactly a new issue, so at least I'd expect to see this documented or perhaps better still, fixed if possible. Below is a little example. When a (non-hardware) breakpoint is planted onto NOP instruction, using System Debugger over JTAG for a ARMv7 (Zynq) target LDR loads a BKPT, not NOP, instruction opcode from the previous PC position. Didn't try, but I guess an accidental (instruction) breakpoint on a data location is no different what comes to the unexpected outcome.



   unsigned int opcode = 0;

 __asm__ __volatile__ (       // Plant the breakpoint here..
  "nop"                  "\n" // ..or for this instruction.
  "ldr  r0, [pc, #-12]"  "\n"
  "mov  %0, r0"          "\n"
    : "=r" (opcode)
    :      // No input
    : "r0" // R0 clobbed

  if (opcode != 0xe320f000u)  // BKPT is 0xe1200070u, which
    fprintf(stderr,           // you'll likely see here.
      "FAIL, read opcode `0x%08x'.\n", opcode);


There are some instructions where you need to extract the immediate value directly from the instruction opcode. As currently SDK doesn't really track (or at least it isn't working properly) breakpoints planted on source code lines they'll move as you'll modify the source code. This may ruin your day, as even the compiled binary blob remains the very same breakpoints may be on different locations based on the source code non-program flow related modifications (i.e. comments and whitespace).

0 Kudos
1 Reply
Xilinx Employee
Xilinx Employee
Registered: ‎10-21-2010

Re: SDK 2015.4, System Debugger does not always restore original opcode for planted breakpoints


Breakpoint instrction is writted to the breakpoint addresses whenever the processor core is resumed. The original instruction is restored when the BP is triggred. When the core is resumed again, the BPs are re-planted so that they remain armed by the time same address it hit next time. So, if you read the address when the core is running, you'll see a breakpoint instruction at the addresses where BP is planted.


Eclipse doesn't update the line breankpoints when the source code changes, unless the line is empty or is a comment

0 Kudos