3

There is a proven way to detect whether a debugger is connected on Cortex-M, as seen here.

I used to as a way to automatically set a breakpoint when I am in a debug session:

void autobreak() {
  if (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk)  { 
      __asm__ __volatile__ ("bkpt #0"); 
  } 
}

I am using J-Link and OpenOCD in CLion for debugging. With autobreak(), the J-Link halts program execution without me manually specifying breakpoints in debug mode. However, it seems that in run mode J-Link still halts program execution which is undesirable for my application.

Let me quickly clarify what I mean by each mode:

  • Run Mode: Only flash program
  • Debug Mode: Flash program then allow user to pause program execution and manually set breakpoints

Is there some way to check whether the J-Link is connected in debug mode or run mode?

Ken Lin
  • 986
  • 1
  • 8
  • 22
  • I think those modes/concepts are at the user level, you, not the hardware level. the jlink has an swd connection to the part, now the part can be halted or running yes, but that is not what you are asking, flashing the part vs setting breakpoints and pausing are all the same mode from the hardware perspective – old_timer Jan 16 '20 at 15:30
  • and the jlink itself is as dumb as the processor and the ocd, it is software that tells it to perform swd commands not the jlink itself. so this sounds like an openocd question. how to use the software. – old_timer Jan 16 '20 at 15:31
  • I see. So is it totally reasonable that autobreak() causes the processor to halt in Run Mode (i.e. flashing the part)? Even though at that instant I don't have direct control to resume program execution? – Ken Lin Jan 17 '20 at 04:28

1 Answers1

0

in cortex-m we have either Halt or monitor mode when it comes to debugging, however what you are saying is more about the cpu state either halted or running .

The code you stated is polling bit 0 of the register DHCSR, that bit can be manipulated only by an access coming from the dap, so if an external debugger is connected then it will have access to the hardware through the DAP interface allowing to set the bit C_DEBUGEN to 1, so whenever we have this external probe connected and we had a running session on your host machine that bit will be always 1 so cpu halted or not that bit will be always set to 1 if you have external debugger connected and therefore your conditional routine will be always executed causing the cpu to be halted.

to avoid that you an use debug monitor routine (not available in cortex-m0/m0+ but available in cortex-m3/m4/m7..), which consist of an internal cpu exception and whenever a software breakpoint or pre programmed hardware breakpoint executed/matched or even explicit halt of cpu done then an internal exception is generated and jump occurs to debug monitor exception with this debug monitor the C_DEBUGEN will be always 0 and not set at all.

dhokar.w
  • 386
  • 3
  • 6