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:
a breakpoint unit supporting two literal comparators and six instruction comparators, or only two instruction comparators
a watchpoint unit supporting one or four watchpoints.
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.
To identify the Cortex-M3 processor within the CoreSight system, ARM recommends that a debugger perform the following actions:
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.