SoC
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
  • Arm Cortex M3
  • Contact
Reading: What is the debug subsystem in arm?
SUBSCRIBE
SoCSoC
Font ResizerAa
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
Search
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
Have an existing account? Sign In
Follow US
  • Looking for Something?
  • Privacy Policy
  • About Us
  • Sitemap
  • Contact Us
© S-O-C.ORG, All Rights Reserved.
Arm

What is the debug subsystem in arm?

Scott Allen
Last updated: September 11, 2023 3:48 am
Scott Allen 10 Min Read
Share
SHARE

The debug subsystem in ARM processors provides hardware support for debugging code running on the processor. It allows external debug tools to halt execution, examine processor state like registers and memory, set breakpoints, and more. The key components of the ARM debug subsystem are:

Contents
Debug Access Port (DAP)BreakpointsDebug Exception and Monitor ModeEmbedded Cross Trigger InterfaceTrace FlowDebug AuthenticationCoreSight ComponentsSummaryUsing the Debug SubsystemDebugger IntegrationValidating Code ChangesAnalyzing Memory CorruptionTracing Execution FlowProfiling and StatisticsChecking Interrupt LatencyAnalyzing Multicore InteractionsHow Debug Subsystem Works InternallyDebug StateMonitor ModeDebug Context SavingDAP Debug Register AccessInstruction SteppingExit and ResumeDebug Subsystem Hardware BlocksDebug Access Port (DAP)Debug Communications Channel (DCC)Breakpoint Control UnitDebug Power and Reset ControlCross Trigger Interface (CTI)Instrumentation Trace Macrocell (ITM)Embedded Trace Macrocell (ETM)Conclusion

Debug Access Port (DAP)

The Debug Access Port (DAP) provides the interface for an external debugger to access the processor’s debug features. The DAP has several registers that can be used to halt/resume execution, access processor registers, set breakpoints, and more. It uses the JTAG interface standard so external JTAG debug probes can connect to it.

Breakpoints

ARM processors support different types of breakpoints through its debug hardware:)

  • Software breakpoints – The processor can be halted when it executes a particular instruction address.
  • Watchpoints – Watchpoints can be set on data addresses to halt the processor when they are read from or written to.
  • Exception breakpoints – These cause a debug halt when a particular exception or fault occurs.

The breakpoints are managed through the DAP debug registers. Multiple breakpoints of each type are supported.

Debug Exception and Monitor Mode

When a breakpoint or watchpoint triggers, the ARM core will enter debug state. This causes it to jump to Monitor mode, a special privileged mode for debugging, and take the debug exception. Monitor mode has access to all system resources needed for debugging like register access. The debugger communicates with Monitor mode through the DAP to control execution and read processor state.

Embedded Cross Trigger Interface

In multicore ARM systems, the embedded cross trigger interface allows coordination between multiple connected cores. Trigger events can be propagated between different CPUs using this. For example, a breakpoint hit on one core can be configured to halt execution on other cores as well.

Trace Flow

The ARM trace flow hardware collects a stream of trace data from the processor as it executes instructions. This can record things like program flow, performance counters, timestamp information, etc. Trace data is output through the DAP and allows more detailed debugging and profiling of code.

Debug Authentication

For security reasons, the ARM debug components have authentication support. This allowsdebug access to be restricted only to authorized users. Authentication can cover both debug register access through the DAP and trace information capture.

CoreSight Components

ARM CoreSight is a set of standards that define useful debug components like trace encoder, trace decoder, debug bus master, etc. ARM processors include some of these components to augment their debug capabilities. For example, a CoreSight program trace macrocell can provide instruction trace information to the DAP.

Summary

In summary, the key aspects of the ARM debug subsystem are:

  • Debug Access Port interface for debugger connection.
  • Breakpoints, watchpoints and exceptions to control program execution.
  • Monitor mode to handle debug exceptions.
  • Multicore cross triggering.
  • Trace flow hardware for logging debug data.
  • Debug authentication for security.
  • CoreSight components to enhance debugging.

This comprehensive debug support allows powerful real-time debugging and profiling on ARM processors. Both software tools and hardware probes can connect to the subsystem to analyze system state and software behavior during execution. The flexible DAP and breakpoint architecture offer non-intrusive and robust debugging. Trace capabilities enable inspection of dynamic program flow. And the multicore triggering allows synchronized debugging across multiple CPUs.

Using the Debug Subsystem

For programmers working on ARM, utilizing the debug subsystem during development can greatly help accelerate coding and testing. Some common use-cases are:

Debugger Integration

Tools like GDB can connect to the DAP interface to enable run-control and breakpoint debugging right within the normal coding workflow. IDEs like Eclipse, Visual Studio Code, etc. provide front-ends to integrate this debugger connection.

Validating Code Changes

Setting breakpoints and examining program state when they are hit is a fast way to validate code changes. The debugger can step through execution flow statement-by-statement to home in on any issues.

Analyzing Memory Corruption

Memory watchpoints allow tracking unauthorized memory accesses that could cause corruption. If an area of memory is hit unexpectedly, the debugger can halt the system to analyze the situation.

Tracing Execution Flow

Trace data gives insight into code hotspots, branching behavior, stalls, and function calls/returns. This helps optimize performance or identify anomalies.

Profiling and Statistics

The trace macros can record timing data, performance counters, and other statistics as code executes. This profiling information enables optimization of slow code areas.

Checking Interrupt Latency

Measuring the time from an interrupt trigger to the handler code executing provides valuable latency data that impacts real-time performance.

Analyzing Multicore Interactions

Using cross-triggers, a developer can debug issues arising from interactions between multiple CPUs working together.

The ARM debug subsystem enables all these use cases and more. Proper utilization of its powerful hardware capabilities can greatly boost debugging productivity during embedded software development.

How Debug Subsystem Works Internally

Under the hood, the ARM debug subsystem relies on a few key mechanisms to enable non-intrusive debugging:

Debug State

Executing the DMCR instruction via the DAP causes the processor to enter debug state. This halts normal execution and gates the clocks to hold the core in its current state. Debug logic remains active.

Monitor Mode

The core switches to Monitor mode privilege when in debug state. This allows full access to system resources needed for debugging. The PC also jumps to the debug exception vector.

Debug Context Saving

On debug entry, the core’s general purpose registers, special registers and CP15 context are saved by hardware to System mode memory. This preserves the processor state for inspection.

DAP Debug Register Access

In Monitor mode, the JTAG DAP interface provides access to the breakpoints, watchpoints, and other debug control registers. These facilitate examining and modifying state.

Instruction Stepping

The step-over and step-into instructions use debug hardware to increment the PC by one instruction and re-enter debug state. This enables single stepping through code execution.

Exit and Resume

The DAP debug registers are used to exit debug state, restoring the saved context and resuming normal execution at the point it left off.

This behind-the-scenes workflow is what enables non-invasive inspection and control of processor state for debugging purposes.

Debug Subsystem Hardware Blocks

The ARM debug subsystem encompasses several hardware blocks integrated into the SoC design. These work together to enable the debug capabilities discussed earlier.

Debug Access Port (DAP)

The DAP is the interface block that a debugger uses to communicate with the debug subsystem. It exposes registers to control debug features and processor state.

Debug Communications Channel (DCC)

The DCC provides a message passing mechanism for communicating small packets of data between the external debugger and the target processor.

Breakpoint Control Unit

This unit contains the breakpoint and watchpoint registers that configure debug break events and their handling.

Debug Power and Reset Control

Power and reset control logic manages the debug components’ power states and resets.

Cross Trigger Interface (CTI)

The CTI implements the cross-trigger matrix between multiple processors for coordinated debugging.

Instrumentation Trace Macrocell (ITM)

ITM provides the processor-driven trace data output capabilities, sending trace data to the DAP.

Embedded Trace Macrocell (ETM)

ETM implements instruction trace capabilities for data like program flow tracing and timing information.

These blocks and more work in conjunction to give ARM processors advanced integrated debug capabilities with minimal overhead or intrusion.

Conclusion

In summary, the ARM debug subsystem provides a versatile set of hardware-based debugging features for embedded software development. Its debug access port and extensive breakpoint support enable powerful control over program execution. Monitor mode grants full system access when debugging. Multicore cross triggering allows coordinated debugging. And trace capabilities facilitate detailed profiling. Together, these capabilities allow ARM developers to debug even the most complex systems and software interactions quickly and efficiently.

Newsletter Form (#3)

More ARM insights right in your inbox

 


Share This Article
Facebook Twitter Email Copy Link Print
Previous Article What are the different debug interfaces that are available on the Cortex-M processor?
Next Article What is the difference between ARM Cortex-A and ARM Cortex-M?
Leave a comment Leave a comment

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

2k Followers Like
3k Followers Follow
10.1k Followers Pin
- Sponsored-
Ad image

You Might Also Like

STR instructions in Arm Cortex-M

The STR (store register) instructions in Arm Cortex-M processors are…

8 Min Read

Why is ARM lower power than x86?

ARM processors are generally known for being more power efficient…

6 Min Read

Options for Debugging ARM Cortex-M1 on Altera FPGAs

Debugging ARM Cortex-M1 processors implemented on Altera FPGAs can be…

6 Min Read

What is ARM Cortex-M1?

The ARM Cortex-M1 processor is a 32-bit reduced instruction set…

7 Min Read
SoCSoC
  • Looking for Something?
  • Privacy Policy
  • About Us
  • Sitemap
  • Contact Us
Welcome Back!

Sign in to your account