7.1. About debug

The processor implementation determines the debug configuration, including whether debug is implemented. If the processor does not implement debug, no ROM table is present and the halt, breakpoint, and watchpoint functionality is not present.

Basic debug functionality includes processor halt, single-step, processor core register access, Vector Catch, unlimited software breakpoints, and full system memory access. See the ARMv7-M Architectural Reference Manual for more information.The debug option might include:

For processors that implement debug, ARM recommends that a debugger identify and connect to the debug components using the CoreSight debug infrastructure.

Figure 7.1 shows the recommended flow that a debugger can follow to discover the components in the CoreSight debug infrastructure. In this case a debugger reads the peripheral and component ID registers for each CoreSight component in the CoreSight system.

Figure 7.1. CoreSight discovery

To identify the Cortex-M3 processor within the CoreSight system, ARM recommends that a debugger perform the following actions:

  1. Locate and identify the Cortex-M3 ROM table using its CoreSight identification. See Table 7.1 for more information.

  2. Follow the pointers in that Cortex-M3 ROM table:

    1. System Control Space (SCS)

    2. Breakpoint unit (BPU)

    3. Data watchpoint unit (DWT).

    See Table 7.2 for more information.

When a debugger identifies the SCS from its CoreSight identification, it can identify the processor and its revision number from the CPUID register in the SCS at address 0xE000ED00.

A debugger cannot rely on the Cortex-M3 ROM table being the first ROM table encountered. One or more system ROM tables are required between the access port and the Cortex-M3 ROM table if other CoreSight components are in the system. If a system ROM table is present, this can include a unique identifier for the implementation.

Copyright © 2005-2008, 2010 ARM Limited. All rights reserved.ARM DDI 0337H