The µVision debugger provides a single environment in which you may test, verify, and optimize your application code. It includes traditional features like simple and complex breakpoints, watch windows, and execution control and provides full visibility to device peripherals. The µVision debugger connects to:
- Target hardware, attached to the PC via a supported debug adapter
- A simulation model that helps to start code verification early without the necessity for target hardware.
Depending on the Arm CoreSight unit in the target Cortex-M based device, the µVision debugger provides advanced real-time debug, trace, and analysis capabilities:
- Component Viewer, Event Recorder, and Event Statistics show execution status, event, timing, and power information about the application execution.
- System Analyzer enables graphical analyses of the overall system performance.
- Data and Event Trace outputs details about interrupts and exceptions. It also communicates program events and enables printf-style debug messages.
- Instruction Trace streams the complete program execution for recording and analysis.
- Execution timing is summarized in the Performance Analyzer and available for code statements.
Component viewer and event recorder
The Component Viewer window shows variables and structures of software components. The Event Recorder window lists captured events of software components. Both do not require special debug capabilities of the target hardware. They use memory reads and writes to show information about:
- Software components that are provided in static memory variables or structures.
- Objects that are addressed by an object handle.
- Execution status and event information of software components.
Event recorder benefits
- Visibility to the dynamic execution of an application at little (memory) cost.
- Adding printf re-targeting for devices without ITM, such as Arm Cortex-M0/M0+/M23.
- Fast time-deterministic execution of Event Recorder functions with minimal code and timing overhead.
- No need for a debug or release build as the event annotations can remain in production code.
- Saving the event data in local memory ensures fast recording.
- Collecting the data from the on-chip memory is done using simple read commands and can be done with any debug adapter.
The Event Statistics window shows you statistical data about the code execution. Benefits include:
- Collect statistical data about the code execution (time and energy).
- Log files enable comparisons between different build runs in continuous integration (CI) environments.
- Improve overall code quality and energy profile (especially relevant for battery driven applications).
Any debug adapter can be used to record execution timing and number of calls for annotated code sections. Energy profiling of annotated code sections is possible using ULINKplus.
The System Analyzer window can be used with any Arm Cortex-M based device for graphical analysis of the overall system behavior. It shows:
- Power measurement data (requires ULINKplus).
- Exceptions (requires SWO trace and ULINKpro or ULINKplus).
- Value changes of VTREGs or variables (requires SWO trace).
- Incoming events from Event Recorder.
- Keil RTX5 RTOS thread events and status.
Data and event trace
All Armv7-M and Armv8-M based devices provide data and event trace. MDK provides a number of ways to analyze this information while your system is running:
- Trace Data Window - Displays program flow by capturing timestamps, PC samples, exceptions, and memory read/write accesses.
- Debug (printf) Viewer - Displays data streams that are transmitted sequentially through the Instrumented Trace Macrocell (ITM), Port 0.
- Trace Exceptions Window - Displays statistical data about program exceptions and interrupts.
- Event Counters - Display real-time values of specific event counters providing performance indications.
- Logic Analyzer - Graphically displays variable values over time.
Many Armv7-M and Armv8-M based devices incorporate an Embedded Trace Macrocell (ETM) which provides instruction trace. The ULINKpro streams instruction trace directly to your computer, enabling debugging of historical sequences, execution profiling, performance optimization, and code coverage analysis.
The virtually unlimited stream of trace information enables MDK to provide complete code coverage of your program. Code coverage identifies every instruction that has been executed, ensuring thorough testing of your application. This is an essential requirement for complete software verification and certification.
ULINKpro allows applications to be run for long periods of time while collecting trace information. This is used by Performance Analyzer to record and display execution times for functions and program blocks. It shows the processor cycle usage and enables you to identify algorithms that require optimization.
Having recorded your application, the Execution Profiler shows timing or execution statistics for the complete program code.
µVision allows developers to execute and debug their programs on simulated Arm processors without using a physical target hardware.
Arm Fixed Virtual Platforms (FVPs) are complete simulations of Arm systems, including processor, memory and peripherals. FVPs for Cortex-M cores are available with the MDK-Professional edition or free-of-charge. µVision can use the Fast Models Debugger Driver for debugging applications simulated with FVPs. Refer to the page Fast Models Debugger Configuration for more information. For legacy architectures and some Cortex-M cores, µVision also provides instruction set simulations.
Powerful µVision debug capabilities such as Event Recorder, Data and Event Trace, and Code Coverage are fully supported on simulations as well.
Simulation pros and cons
- Early Access: Dynamic testing is available at every stage of software development.
- No Hardware Required: Proof of concept testing before hardware design is done.
- Inject Dangerous Faults: Simulate conditions critical to hardware without risk.
- Full Visibility: Simulation traces data, registers and instructions and gives a full insight into the system to analyze failures.
- Peripheral Access: Software access to peripheral registers cannot be tested in most cases or will behave differently (refer to KB 3726).
- Memory Timing: Any simulation can only assume ideal conditions for memory access. It does not simulate wait states for data or code fetches.