Debugger Detection Under Software Control on EFM32, EFR32, and EZR32
10/275/2018 | 05:28 PM
We're using Flex Gecko and want to know if there is a way in software to detect if a debugger is connected? There are times when we might want our software to behavior differently or provide access to certain functions if we know the system is operating under debug control.
This is a question that many EFM32, EFR32, and EZR32 customers might have. It's also one that ARM would seem to have addressed given how device operation is governed by debug status.
The Debug Halting Control and Status Register (DHCSR) at 0xE000EDF0 in core space provides fundamental control of basic CPU operation, e.g. halting and stepping the core. Bit 0 of this register is the C_DEBUGEN bit, which, as it's name implies, is the control bit that enables debug.
Some users might see this and immediately think that it's possible to enable debug mode, or, better still, force debugger disconnection, under software control. Alas, this is not the case because, as ARM's documentation makes clear, C_DEBUGEN "can only be written by (the) AHB-AP and not by the core. It is ignored when written by the core, which cannot set or clear it."
What is the AHB-AP? The AMBA High-Performance Bus - Access Port is the name for what ARM calls a memory access port, a block intended for use by the Cortex M-series software debug (SWD) interface to read and write memory and registers present on the AHB.
Even though the CPU cannot write C_DEBUGEN, it is able to read it. This effectively makes it a status bit, thus providing a means for software to modify its behavior when under debugger control.
NOTE: This applies only to devices using the Cortex-M3 and Cortex-M4 cores. ARM provides various register macros to access the Debug Control Block (DCB) registers in their CMSIS header files. The following comment is found in core_cm0plus.h for the Cortex-M0+:
/**
\ingroup CMSIS_core_register
\defgroup CMSIS_CoreDebug Core Debug Registers (CoreDebug)
\brief Cortex-M0+ Core Debug Registers (DCB registers, SHCSR, and DFSR) are only accessible over DAP and not via processor.
Therefore they are not covered by the Cortex-M0+ header file.
@{
*/
/*@} end of group CMSIS_CoreDebug */
The Silicon Labs EFM32 devices that use the Cortex-M0+ (Zero Gecko, Happy Gecko, and Series 1 Tiny Gecko), therefore, do not provide CPU visibility of the DCB registers.
Knowledge Base Articles
32-bit MCUs
On cortex M0, some have diverted the brk hardware fault routine, as it does not happens when debugger is attached.
But simplest way is to just have the debugger change a flag before it runs, using C-spy macro.
check Use Macro file(s) in Debugger Setup page, create a mymacro.mac text file.
execUserSetup()
{
isdebug = 0xFEEDC0DE;
}
and in your code:
__no_init uint32_t isdebug;
if ( isdebug == 0xFEEDC0DE){...}
isdebug = 0;
But most of the time you just want to treat initial download as a powerup reset.
Starting code in debugger mode you only get RMU_RSTCAUSE_SYSREQRST,
but you have a routine looking for RMU_RSTCAUSE_PORST as to treat RAM as trashed.
You have a __no_init area that should be cleared first time code is run from debugger, like the routine you use to clear this area when you see RMU_RSTCAUSE_PORST.
Debugger Detection Under Software Control on EFM32, EFR32, and EZR32
We're using Flex Gecko and want to know if there is a way in software to detect if a debugger is connected? There are times when we might want our software to behavior differently or provide access to certain functions if we know the system is operating under debug control.
This is a question that many EFM32, EFR32, and EZR32 customers might have. It's also one that ARM would seem to have addressed given how device operation is governed by debug status.
The Debug Halting Control and Status Register (DHCSR) at 0xE000EDF0 in core space provides fundamental control of basic CPU operation, e.g. halting and stepping the core. Bit 0 of this register is the C_DEBUGEN bit, which, as it's name implies, is the control bit that enables debug.
Some users might see this and immediately think that it's possible to enable debug mode, or, better still, force debugger disconnection, under software control. Alas, this is not the case because, as ARM's documentation makes clear, C_DEBUGEN "can only be written by (the) AHB-AP and not by the core. It is ignored when written by the core, which cannot set or clear it."
What is the AHB-AP? The AMBA High-Performance Bus - Access Port is the name for what ARM calls a memory access port, a block intended for use by the Cortex M-series software debug (SWD) interface to read and write memory and registers present on the AHB.
Even though the CPU cannot write C_DEBUGEN, it is able to read it. This effectively makes it a status bit, thus providing a means for software to modify its behavior when under debugger control.
NOTE: This applies only to devices using the Cortex-M3 and Cortex-M4 cores. ARM provides various register macros to access the Debug Control Block (DCB) registers in their CMSIS header files. The following comment is found in core_cm0plus.h for the Cortex-M0+:
The Silicon Labs EFM32 devices that use the Cortex-M0+ (Zero Gecko, Happy Gecko, and Series 1 Tiny Gecko), therefore, do not provide CPU visibility of the DCB registers.
On cortex M0, some have diverted the brk hardware fault routine, as it does not happens when debugger is attached.
But simplest way is to just have the debugger change a flag before it runs, using C-spy macro.
check Use Macro file(s) in Debugger Setup page, create a mymacro.mac text file.
But most of the time you just want to treat initial download as a powerup reset.
Starting code in debugger mode you only get RMU_RSTCAUSE_SYSREQRST,
but you have a routine looking for RMU_RSTCAUSE_PORST as to treat RAM as trashed.
You have a __no_init area that should be cleared first time code is run from debugger, like the routine you use to clear this area when you see RMU_RSTCAUSE_PORST.