10.2.4. Debug Exception and Monitor Control Register

The purpose of the Debug Exception and Monitor Control Register (DEMCR) is:

The DEMCR:

Figure 10.2 shows the arrangement of bits in the register.

Figure 10.3. Debug Exception and Monitor Control Register format

Table 10.4 shows the bit functions of the Debug Exception and Monitor Control Register.

Table 10.4. Debug Exception and Monitor Control Register

BitsTypeFieldFunction
[31:25]--Reserved, SBZP
[24]Read/writeTRCENA

This bit must be set to 1 to enable use of the trace and debug blocks:

  • Data Watchpoint and Trace (DWT)

  • Instrumentation Trace Macrocell (ITM)

  • Embedded Trace Macrocell (ETM)

  • Trace Port Interface Unit (TPIU).

This enables control of power usage unless tracing is required. The application can enable this, for ITM use, or use by a debugger.

Note

If the TIEOFF_TRCENA define is uncommented in CM3Defs.v during implementation it is not possible to set TRCENA.

[23:20]--Reserved, SBZP
[19]Read/writeMON_REQ[1]

This enables the monitor to identify how it wakes up:

1 = woken up by MON_PEND

0 = woken up by debug exception.

[18]Read/writeMON_STEPa

When MON_EN = 1, this steps the core. When MON_EN = 0, this bit is ignored. This is the equivalent to C_STEP. Interrupts are only stepped according to the priority of the monitor and settings of PRIMASK, FAULTMASK, or BASEPRI.

[17]Read/writeMON_PENDa

Pend the monitor to activate when priority permits. This can wake up the monitor through the AHB-AP port. It is the equivalent to C_HALT for Monitor debug.

This register does not reset on a system reset. It is only reset by a power-on reset. Software in the reset handler or later, or by the DAP must enable the debug monitor.

[16]Read/writeMON_ENa

Enable the debug monitor. When enabled, the System handler priority register controls its priority level. If disabled, then all debug events go to Hard fault. C_DEBUGEN in the Debug Halting Control and Statue register overrides this bit.

Vector catching is semi-synchronous. When a matching event is seen, a Halt is requested. Because the processor can only halt on an instruction boundary, it must wait until the next instruction boundary. As a result, it stops on the first instruction of the exception handler. However, two special cases exist when a vector catch has triggered:

  • If a fault is taken during vectoring, vector read or stack push error, the halt occurs on the corresponding fault handler, for the vector error or stack push.

  • If a late arriving interrupt comes in during vectoring, it is not taken. That is, an implementation that supports the late arrival optimization must suppress it in this case.

[15:11]--Reserved, SBZP
[10]Read/writeVC_HARDERR[2]

Debug trap on Hard Fault.

[9]Read/writeVC_INTERRb

Debug Trap on interrupt/exception service errors. These are a subset of other faults and catches before BUSERR or HARDERR.

[8]Read/writeVC_BUSERRb

Debug Trap on normal Bus error.

[7]Read/writeVC_STATERRb

Debug trap on Usage Fault state errors.

[6]Read/writeVC_CHKERRb

Debug trap on Usage Fault enabled checking errors.

[5]Read/writeVC_NOCPERRb

Debug trap on Usage Fault access to Coprocessor which is not present or marked as not present in CAR register.

[4]Read/writeVC_MMERRb

Debug trap on Memory Management faults.

[3:1]--Reserved, SBZP
[0]Read/writeVC_CORERESETb

Reset Vector Catch. Halt running system if Core reset occurs.

[1] This bit clears on a Core Reset.

[2] Only usable when C_DEBUGEN = 1.

This register manages exception behavior under debug.

Vector catching is only available to halting debug. The upper halfword is for monitor controls and the lower halfword is for halting exception support.This register is not reset on a system reset.

This register is reset by a power-on reset. Bits [19:16] are always cleared on a core reset. The debug monitor is enabled by software in the reset handler or later, or by the AHB-AP port.Vector catching is semi-synchronous. When a matching event is seen, a Halt is requested. Because the processor can only halt on an instruction boundary, it must wait until the next instruction boundary. As a result, it stops on the first instruction of the exception handler. However, two special cases exist when a vector catch has triggered:

  1. If a fault is taken during a vector read or stack push error the halt occurs on the corresponding fault handler for the vector error or stack push.

  2. If a late arriving interrupt detected during a vector read or stack push error it is not taken. That is, an implementation that supports the late arrival optimization must suppress it in this case.

Copyright © 2005, 2006 ARM Limited. All rights reserved.ARM DDI 0337E
Non-Confidential