Debug
In this topic:
•Cortex-A/R Access Breakpoints
For general debug information refer to the general Debug chapter.
Cortex-A and Cortex-R display different dialogs for Access Breakpoints.
Enable - When checked watchpoint is enabled.
Address - Specify the address which is to be monitored for data access by the core or clicking button "..." open dialog Symbols Browser to add Variables.
Linked - Comparator to be used for linked data address match or mismatch holding Context match.
Mode - Breakpoint debug event generation can be made conditional on the current state of the processor.
Type - Determines the type of access made by the watchpoint (Load, Store, Any).
Context ID - Value used for matching with value in CONTEXTIDR. CONTEXTIDR identifies the current Process Identifier (PROCID) and, when using the Short-descriptor translation table format, the Address Space Identifier (ASID).
VMID - Value for virtual machine identifier matching.
Setting Software Breakpoints on devices with advanced memory access systems is not straightforward as only writing proper instruction at the address of the wanted BP. BKPT instruction might stay in DCACHE and thus not presented to the core fetch mechanism. Additionally ICACHE might not detect that BP instruction was written to underlying memory system. That is why SW BP to memory is set with following steps:
•Cores are stopped if running
•BKPT instruction is written
•DCACHE is cleaned
•ICACHE is invalidated for all cores
•Cores are run if were running before
Cortex-A/R devices offer both the physical memory access (through the memory bus to the on-chip memory) and the virtual memory access (accessing the memory through the core). The difference is significant because both families feature memory caches and the Cortex A family additionally features the memory management unit (MMU). Physical memory access bypasses the cache and the MMU and reads directly from the memory, whereas the virtual access uses the same access chain (data cache, MMU) as the core does. Therefore with a virtual memory access we see the memory as the core does.
Virtual memory access is performed with instruction stuffing. This means the core is fed with memory read / write instructions through a dedicated debug register. However, instruction stuffing is not allowed when the CPU is running. This means that virtual memory access can only be used when the CPU is stopped. When the CPU is running all memory reads and writes are done with physical memory accesses instead. This means the cache and the MMU are bypassed in this case. |
Access breakpoints feature on Cortex-M based MCUs is provided by the DWT (Data Watchpoint Trigger) unit. The DWT can also be used as the optional trace source unit. It provides up to 4 Comparators which support instruction address, data address, data value (Comparator 1 only) and CPU cycle count matching (comparator 0 only). Exact level of comparator function support depends on the DWT implementation on a particular microcontroller. For instance DWT comparators on some microcontrollers may support only address matching and no data value matching. Others may implement both address and data value matching.
winIDEA performs run time check of available debug resources (number of comparators, data value comparison, etc.) when access breakpoints are configured and activated and pops up a warning when some of configured resources are not supported by the microcontroller.
Each DWT comparator can be configured to perform instruction address or data address matching while only comparator 1 can additionally perform data value matching. Comparator 0 can also be configured to perform CPU cycle count matching. When a comparator detects a match it will take the specified action.
The DWT unit is shared between access breakpoints and the trace trigger. Consequently DWT used by one debug functionality is not available for the other functionality. In practice this means that no trace trigger can be set on data access when access breakpoint is configured already and vice versa. |
Access breakpoints dialog is generic for Cortex-M based microcontrollers. The actual dialog window displayed for a specific M-based microcontroller might hide some of the controls depending on the actual DWT hardware implementation on the chip.
Access Breakpoint dialog for Cortex-M devices with architecture version ARMv8-M (Cortex-M23, Cortex-M33 / DA14699).
Since configuring access breakpoints may require deeper knowledge of the available on-chip debug resources, an easy to use Breakpoint Wizard is available, which allows setting up few basic access breakpoints scenarios in few steps. Sometimes it’s also a good starting point for setting up more complex access breakpoints by first configuring basic access breakpoint using Wizard and then adjusting existing or configuring additional fields and options.
On Cortex M3, M4, M7 devices: Hardware Trigger Configuration in the Wizard's Data Value comparator is configurable.