External debug events

In this section of the guide, we describe the debug events that can cause the PE to enter Debug state. Here is a summary of each event:

External debug request debug event
This event is an input trigger event to the processor. When this event is asserted, the PE enters Debug state.
Halt instruction debug event
This event is generated whenever the PE executes an HLT instruction.
Halting step debug event
This event is generated immediately after the PE executes an instruction or an exception, while the PE is not in Debug state.
Exception catch debug event
This event is generated immediately after the PE executes an exception or an exception return.
Reset catch debug event
This event is generated immediately after reset, before the PE begins execution following the reset.
Software access debug event
This event is generated when the PE attempts access to Debug system registers, for example, the breakpoint and watchpoint control registers.
OS unlock catch debug event
This event is generated when the OS lock state changes from locked to unlocked.
Breakpoint event
This event is generated whenever the PE attempts to execute an instruction from a particular address.
Watchpoint event
This event is generated whenever the PE accesses data from a particular address.

Breakpoints and watchpoints are resources that are shared between self-hosted debuggers and external debuggers. If halt mode debug is enabled, a breakpoint event or watchpoint event causes the PE to enter Debug state. Otherwise, a debug exception is generated if self-hosted debug is enabled.

Let’s look at each of these events in more detail.

External debug request event

An external debug request event is an input trigger event to the processor. When this event is asserted, the PE enters Debug state. The debugger asserts an external debug request to force the PE to enter Debug state, and then the external debugger controls the PE. Cross Trigger Interface Registers are used to generate external debug request events.

If an external debug request is asserted when the PE is already in Debug state, the request is ignored. To exit Debug state, the external debugger asserts a restart request to the processor. A restart request is an input signal to the processor. When a restart request is asserted, the processor exits Debug state.

Halt instruction debug event

A halt instruction debug event allows the external debugger to take control of the PE when the PE attempts to execute the HLT instruction. The HLT instruction is the halting software breakpoint instruction. When the HLT instruction is committed for execution, the halt instruction debug event is generated if EDSCR.HDE is 1. On execution of HLT instruction, the PE enters Debug state and gives control to the external debugger.

The debugger usually replaces the program instruction with an HLT instruction to trigger a halt instruction debug event. After this event, the external debugger controls the PE.

To exit Debug state, the external debugger asserts a restart request to the processor.

Halting step debug event

A halting step debug event allows the external debugger to take control of the program that is being debugged. This happens after the PE executes every individual instruction or exception, while the PE is not in Debug state. When halting step debug event is enabled, the PE enters Debug state whenever an instruction or exception is retired in the PE.

Programming a halting step debug event:

  • When the PE is in Debug state, the external debugger enables halting step by writing the EDECR.SS to 1 .
  • The external debugger signals the PE to exit Debug state.
  • After exiting Debug state, the PE executes the instruction that is pointed by the Program Counter (PC). The PE enters Debug state before executing the next instruction, which gives control to the external debugger.

To exit Debug state, the external debugger asserts a restart request to the processor.

Exception catch debug event

An exception catch debug event allows the external debugger to take control whenever the PE executes an exception or exception return. For each Exception level, ED Exception Catch Control Register (EDECCR) includes independent control bits for exception and exception return. Setting the bit in EDECCR forces the PE to enter Debug state when the PE executes an exception, or exception return, with a target Exception level that is indicated in EDECCR.

When an exception catch debug event is generated on exception entry, the PE enters Debug state as part of the exception entry, before the first instruction of the exception handler is executed.

When an exception catch debug event is generated on exception return, the PE enters Debug state, before the execution of the first instruction at the exception return address.

To exit Debug state, the external debugger asserts a restart request to the processor.

Reset catch debug event

A reset catch debug event allows the external debugger to take control of the PE immediately after reset.

To enable a reset catch debug event, set the Reset Catch debug Event (RCE) bit in the External Debug Execution Control Register (EDECR) or Cross Trigger Interface Device Control register (CTIDEVCTL).

When the external debugger sets the RCE bit, the reset catch debug event is generated on a reset of the PE. The PE enters Debug state and gives control to the external debugger, before the execution of the first instruction after reset. The reset can be either a Warm reset or a Cold reset of the PE.

To exit Debug state, the external debugger asserts a restart request to the processor.

Software access debug event

A software access debug event allows the external debugger to take control of the PE when the PE software tries to access the following registers:

  • Debug Breakpoint Value Registers (DBGBVRn_EL1), including DBGBXVRn from AArch32 state
  • Debug Breakpoint Control Registers (DBGBCRn_EL1)
  • Debug Watchpoint Value Registers (DBGWVRn_EL1)
  • Debug Watchpoint Control Registers (DBGWCRn_EL1)

The external debugger can enable the software access debug event by setting the TDA-bit in the External Debug Status and Control Register (EDSCR).

When the external debugger sets the TDA bit, the PE enters Debug state, and provides control to the external debugger when the PE software tries to access any of the following Debug system registers:

  • AArch64: DBGBCR<n>_EL1, DBGBVR<n>_EL1, DBGWCR<n>_EL1, DBGWVR<n>_EL1.
  • AArch32: DBGBCR<n>, DBGBVR<n>, DBGBXVR<n>, DBGWCR<n>, DBGWVR<n>.

Memory mapped accesses to the above registers do not generate a software access debug event.

To exit Debug state, the external debugger asserts a restart request to the processor.

OS unlock catch debug event

Some Debug register contents are lost during powerdown of the PE. To enable the debugging ability of the processor after reset, Debug register contents must be saved into a non-volatile memory before the powerdown, and restored when the system comes out of reset. The Armv8-A architecture enables saving of Debug register contents with the OS save mechanism and restoring the Debug register contents with the OS restore mechanism.

The PE software performs the save restore. While saving the Debug register contents, the PE software locks the OS lock so that external debug accesses to Debug registers are forbidden. After restoring the Debug register contents, the PE software unlocks the OS lock.

The OS unlock catch debug event allows the external debugger to take control of the PE, immediately after the OS restore sequence. This event forces the PE to enter Debug state, immediately after restoring the Debug register contents after reset.

The control bit EDECR.OSUCE enables an OS unlock catch debug event.

Breakpoint event

A breakpoint event is generated whenever the PE tries to execute an instruction from a particular address. Hardware breakpoint registers can be programmed with the address of a program. When the PE tries to execute an instruction from the programmed address, a breakpoint event is generated.

When a breakpoint event is generated, it generates an entry to Debug state if:

  • EDSCR.HDE == one. Halting debug is enabled for these events.
  • Authentication signals indicate that debugger has sufficiently authenticated itself for the current Security state of the PE.

Breakpoint setup uses hardware registers, so is commonly referred to as hardware breakpoint.

Steps to program a breakpoint event:

  • The external debugger programs the address of the instruction into the Breakpoint Value Register DBGBVR.
  • The external debugger sets the enable bit DBGBCR.E to enable the breakpoint event.

The following diagram illustrates a breakpoint event in which the PE tries to execute a SUB instruction for which a breakpoint is set up:

Breakpoint event
Breakpoint event

Hardware breakpoints can be programmed to generate a breakpoint event, based on the following breakpoint matches when the PE executes:

Unlinked instruction address match
The PE executes from a virtual address with the same value as the DBGBVR register, and the current state of the PE matches the settings in DBGBCR.
Unlinked Context ID match
The PE executes an instruction while CONTEXTIDR_EL1/CONTEXTIDR_EL2 is the same as the DBGBVR register, and the current state of the PE matches with the settings in DBGBCR. DBGBCR.BT defines whether CONTEXTIDR_EL1 or CONTEXTIDR_EL2 is used. These breakpoints are useful to route the control to the external debugger when an application or operating system is scheduled for execution.
Unlinked VMID match
The PE executes an instruction while VTTBR_EL2.VMID matches the DBGBVR register contents, and the current state of the PE matches the settings in DBGBCR. These breakpoints are useful to route the control to the external debugger when an operating system is scheduled for execution.
Unlinked Context ID and VMID match
The PE executes an instruction while CONTEXTIDR_EL1 and VTTBR_EL2.VMID matches the contents DBGBVR register, and the current state of the PE matches the settings in DBGBCR. These breakpoints are useful to route the control to the external debugger when an application in an operating system is scheduled for execution.
Linked breakpoints
Address matching breakpoints can be linked to context or VMID breakpoints. These breakpoints are useful to route the control to the external debugger when the PE executes from an instruction address in an application or operating system, or an application within an operating system.

The Breakpoint Control Register, DBGBCR<n>_EL1, contains controls for the breakpoint, for example an enable control.

The Breakpoint Value Register, DBGBVR<n>_EL1, holds the value that is used for breakpoint matching. This value is one of the following:

  • An instruction virtual address
  • One or two Context IDs
  • A VMID value
  • A concatenation of both a Context ID value and a VMID value

The Armv8-A architecture provides for 2-16 hardware breakpoints to be implemented. How many hardware breakpoints an implementation supports is an IMPLEMENTATION DEFINED choice. Depending on the availability of the hardware breakpoint units, that number of hardware breakpoints can be simultaneously set up on an implementation. The register ID_AA64DFR0_EL1.BRPs indicates how many breakpoint units are implemented.

Individual breakpoint unit can be enabled or disabled by programming the E-bit of the individual debug breakpoint control register, DBGBCR<n>_El1.E.

Each breakpoint unit has a corresponding control register. Depending on how many breakpoints are implemented, the registers are numbered in line with this, so that:

  • DBGBCR0_EL1 and DBGBVR0_EL1 are for breakpoint number zero.
  • DBGBCR1_EL1 and DBGBVR1_EL1 are for breakpoint number one.
  • DBGBCR2_EL1 and DBGBVR2_EL1 are for breakpoint number two.
  • DBGBCR<n>_EL1 and DBGBVR<n>_EL1 are for breakpoint number n.
Watchpoint event

A watchpoint event is generated when a PE accesses data memory from a particular address or address range. Hardware watchpoint registers can be programmed with the address of a data memory location. When the PE attempts to access data from the programmed address, a watchpoint event is generated.

When a watchpoint event is generated, the PE enters Debug state if:

  • EDSCR.HDE == 1, Halting debug is enabled for these events.
  • Authentication signals indicate that the debugger has sufficiently authenticated itself for the current Security state of the PE.

A watchpoint never generates a watchpoint debug event on an instruction fetch.

These are the steps to program a watchpoint event, in this order:

  • The external debugger programs the address of the data into the watchpoint value register, DBGWVR.
  • The external debugger enables the watchpoint in the Watchpoint Control Register, DBGWCR by setting the enable bit DBGWCR.E.

The following diagram illustrates a watchpoint event when the PE tries to execute an instruction for which a watchpoint is set up:


Watchpoint event

Lower bits of DBGWVR can be masked in the address comparison. This allows the ED to set a watchpoint event over a range of addresses.

A watchpoint can be:

  • Programmed to generate watchpoint debug events on read accesses only, on Write-Accesses only, or on both types of access
  • Linked to a Linked Context breakpoint, so that a watchpoint debug event is only generated if the PE is in a particular context when the address match occurs

The Armv8-A architecture provides for 2-16 hardware watchpoints to be implemented. How many hardware watchpoints an implementation supports is an IMPLEMENTATION DEFINED choice . Depending on the availability of the hardware watchpoint units, that number of watchpoints can be simultaneously set up on an implementation. The ID_AA64DFR0_EL1.WRPs register indicates how many watchpoint units are implemented.

An individual watchpoint unit can be enabled or disabled by programming the E-bit of the individual debug watchpoint control register, DBGWCR<n>_EL1.E.

Each watchpoint unit has a corresponding control register. Depending on how many watchpoints are implemented, the registers are numbered in line with this, so that:

  • DBGWCR0_EL1 and DBGWVR0_EL1 are for watchpoint number zero.
  • DBGWCR1_EL1 and DBGWVR1_EL1 are for watchpoint number one.
  • DBGWCR2_EL2 and DBGWVR2_EL1 are for watchpoint number two.
  • DBGWCR<n>_EL1 and DBGWVR<n>_EL1 are for watchpoint number n.
Previous Next