What are breakpoint comparators in Arm Cortex-M series?

Breakpoint comparators are hardware debug features in Arm Cortex-M series microcontrollers that allow developers to set breakpoints based on data accesses rather than just instruction addresses. This enables more powerful and flexible debugging by pausing execution when specific memory addresses are accessed or certain values are present in registers or memory.

Overview of Arm Cortex-M Debug Architecture

All Cortex-M processors contain an embedded debug module called the CoreSight Debug Access Port (DAP). This provides a debug interface to external debug probes and hosts. The DAP has several key components:

• Debug Port (DP): The external interface used by debug probes.
• Access Port (AP): Provides access to the core’s internal debug components.
• Debug Control and Configuration Register (DCC): Used to configure debugging.
• Instrumentation Trace Macrocell (ITM): Logs and outputs tracing data.
• Embedded Trace Macrocell (ETM): More advanced instruction and data tracing.

Attached to the AP are additional debugging resources like breakpoint comparators, watchpoint comparators, and other specialized registers. These are controlled through the AP to inspect and alter microcontroller state during debugging sessions.

Breakpoint Comparators

Breakpoint comparators allow breakpoints to be set based on data accesses rather than just instruction fetches. Up to 16 breakpoint comparators are available in Cortex-M3 and newer microcontrollers. Each comparator consists of several registers:

• Comparator register: Holds the data address value to compare against.
• Mask register: Contains a bit mask that determines which bits of the address are compared.
• Control register: Configures the comparator’s operation mode.
• Match register: Set when a match occurs between the comparator and access addresses.

During execution, the breakpoint comparators monitor bus activity. When a data access occurs, the address is compared against the values in the comparator registers. If a match occurs after applying the mask, the corresponding match register is set and a debug event triggered.

Comparator Modes

The comparator control registers allow different types of breakpoints to be specified:

• Address range: Break on accesses inside or outside an address range.
• Exact match: Break on accesses to a specific address.
• N-bit mask: Break on accesses where masked address bits match.

The mask registers provide additional flexibility in all modes by allowing ignore bits to be specified. This enables triggering on ranges larger than natural word sizes.

Debug Exceptions

When a comparator match occurs, a debug event is triggered. This causes a DebugMonitor or DebugHalting debug exception to be raised, depending on configure settings. The core will then halt or enter debug state, allowing inspection of registers and memory.

Debug handlers can identify the source comparator from the debug exception registers. The match registers can also be directly checked to see which comparator matched.

Using Breakpoint Comparators

Here are some examples of how breakpoint comparators enable more advanced debugging:

• Data range profiling: Set an address range breakpoint to count accesses to a data structure.
• Memory change tracking: Break when specific variable or register values are written.
• Execution flow: Break when entering or exiting a function.
• FIFO access: Break on out-of-bounds FIFO index accesses.

Breakpoint comparators can be set and cleared under software control during debugging sessions. This allows dynamic alterations and provides much more debugging power than static hardware breakpoints.

Comparator Usage Considerations

There are some limitations to keep in mind when using breakpoint comparators:

• Only data reads and writes are compared, not instruction fetches.
• Matching is performed on physical addresses prior to any MMU translation.
• Comparisons may have a performance impact even when no match occurs.
• Nesting of multiple comparators should be avoided.

Properly configuring comparators only when needed and minimizing comparisons per access is recommended. Comparator patterns should also be kept simple where possible.

Debug Access Port (DAP)

The Debug Access Port (DAP) provides the external interface through which debug probes and hosts can access the Cortex-M debug components like breakpoint comparators. The DAP uses a standard Arm interface protocol similar to JTAG but with extra debugging features. Key DAP properties include:

• Multiplexed pin access: Up to 4 debugger pins multiplexed with up to 8 data pins.
• JTAG TAP compatibility: DAP TAP protocol is superset of JTAG.
• Fast parallel access: Full AP register access in as little as 2 clocks.
• Multiple APs: Support for up to 224 APs to debug multiple cores.

This optimized debug interface enables breakpoint comparators and other debugging resources to be efficiently utilized with minimal intrusion on normal processor operation.

Debug Port

The Debug Port (DP) is the specific component of the DAP that provides the external interface. This handles the DAP packet protocol and multiplexing of debugger pins. DP properties include:

• Up to 4 multiplexed debugger pin connections.
• JTAG interface pins: TCK, TMS, TDI, TDO.
• Asynchronous debug interface.
• Daisy chaining support of multiple DPs.

The DP allows communication and control with external debug probes. It provides the gateway into the internal debug components of the Cortex-M system.

Access Port

The Access Port (AP) interfaces between the DP and on-chip resources like the DCC, ITM, and breakpoint comparators. It handles multiplexed access to the different debug registers and components. Key AP attributes:

• Up to 224 APs with separate register memory map spaces.
• Atomic and parallel access modes.
• Access protection and privilege configurations.
• Multi-layer AHB bus interface handling.

The AP thus provides the main control interface for configuring and accessing breakpoint comparators during debug sessions.

Using Breakpoint Comparators

Here is an example workflow for utilizing breakpoint comparators during a debugging session:

1. Connect and identify the target microcontroller using a debug probe.
2. Halt execution of the core to configure breakpoints.
3. Write comparator register addresses and masks via the AP.
4. Configure comparator control settings like modes.
5. Clear match registers and resume core execution.
6. On a comparator match, core will halt again or raise debug exception.
7. Inspect match registers, stacks, and system state.
8. Clear match registers or alter breakpoints as needed.
9. Resume execution and repeat process.

Comparators are typically set specific to use cases like monitoring a variable change or memory range access. Multiple comparators can be chained together for more complex breakpoint conditions.

Comparator Resources

Proper configuration of breakpoint comparators requires awareness of comparator availability and limitations. Key implementation details include:

• Up to 16 comparators, Cortex-M3 and newer.
• Comparators share watchpoint resources.
• Specific comparator address bits depend on microarchitecture.
• Match registers are sticky until reset.
• Nested comparators may have cross-interference.

Consult your specific device reference manual for details on comparator addressing, masking, and available resources. Comparator patterns should be tested thoroughly before deployment.

Summary

Breakpoint comparators provide data address-driven breakpoints for powerful and flexible debugging on Arm Cortex-M series microcontrollers. By halting execution or raising debug exceptions on specific memory accesses, system state can be inspected when conditions occur.

Comparators expand debugging capabilities beyond simple instruction breakpoints. Properly utilizing comparators enables tracking of data writes, profiling memory ranges, restricting accesses, and monitoring variable changes. This gives great insight into real-time system behavior.

With their inclusion on the standard CoreSight debug architecture, breakpoint comparators are readily available tools for firmware developers using Cortex-M devices. As with any specialized hardware feature, proper configuration and limitations awareness are key to harnessing their full debugging potential.