Post

Debuggers

Debuggers

Overview

Debugging embedded systems requires specialized hardware interfaces and protocols to communicate with microcontrollers. This guide covers the most common debug interfaces (JTAG, SWD, CMSIS-DAP) and popular debugger hardware (J-Link, ST-Link, DAPLink), explaining their use cases, advantages, and limitations.

Debug Interface Protocols

JTAG (Joint Test Action Group)

JTAG is the original IEEE 1149.1 standard for testing and debugging integrated circuits.

Protocol Characteristics

  • Pins Required: 4-5 pins (TDI, TDO, TCK, TMS, optional TRST)
  • Speed: Typically 1-50 MHz
  • Daisy Chain: Supports multiple devices on same bus
  • Voltage: 1.8V to 5V depending on implementation

Technical Details

1
2
3
4
5
6
JTAG Signals:
- TCK  (Test Clock)      - Clock signal
- TMS  (Test Mode Select) - Controls state machine
- TDI  (Test Data In)    - Serial data input
- TDO  (Test Data Out)   - Serial data output  
- TRST (Test Reset)      - Optional reset (can use TMS instead)

Use Cases

  • Complex SoCs with multiple cores
  • FPGA programming and debugging
  • Boundary scan testing
  • Production testing environments
  • When multiple devices need debugging simultaneously

Advantages

  • Industry standard with broad support
  • Robust and well-established protocol
  • Supports complex multi-device scenarios
  • Excellent for production testing

Disadvantages

  • Requires more pins (4-5 vs 2-3 for SWD)
  • More complex implementation
  • Higher power consumption

SWD (Serial Wire Debug)

SWD is ARM’s proprietary 2-wire debug protocol, designed as a more efficient alternative to JTAG.

Protocol Characteristics

  • Pins Required: 2 pins (SWDIO, SWCLK)
  • Speed: Up to 50 MHz (typically 1-10 MHz)
  • Voltage: 1.8V to 5V
  • Direction: Bidirectional data on single wire

Technical Details

1
2
3
4
SWD Signals:
- SWCLK (Serial Wire Clock)     - Clock signal
- SWDIO (Serial Wire Data I/O)  - Bidirectional data
- SWO   (Serial Wire Output)    - Optional trace output

Use Cases

  • ARM Cortex-M/A/R debugging
  • Space-constrained PCB designs
  • High-speed debugging requirements
  • Modern embedded development

Advantages

  • Fewer pins required (2 vs 4-5 for JTAG)
  • Higher performance potential
  • Lower power consumption
  • Built into all ARM Cortex processors
  • Supports advanced features like ETM tracing

Disadvantages

  • ARM-specific (not universal like JTAG)
  • Cannot daisy-chain multiple devices
  • Less suitable for production testing
  • Requires ARM-compatible tooling

CMSIS-DAP (Cortex Microcontroller Software Interface Standard)

CMSIS-DAP is ARM’s standardized firmware specification for debug adapters.

Architecture Overview

1
Host PC <-- USB --> CMSIS-DAP Adapter <-- SWD/JTAG --> Target MCU

Key Features

  • Transport: USB HID or USB Bulk endpoints
  • Protocols: Supports both SWD and JTAG
  • Open Source: Reference implementation available

Use Cases

  • Cross-platform debugging
  • Custom debugger hardware
  • Educational projects
  • Cost-sensitive applications
  • When vendor independence is required

Advantages

  • Vendor-neutral standard
  • Open source implementation
  • USB-based (no special drivers needed)
  • Supports multiple debug protocols
  • Cost-effective implementation

Disadvantages

  • Generally slower than proprietary solutions
  • Limited advanced features
  • Less optimization than vendor-specific tools
  • May lack specialized MCU support

Segger’s J-Link is a professional-grade debug probe family.

Product Variants

1
2
3
4
5
J-Link Models:
- J-Link BASE     - Entry-level, basic debugging
- J-Link PLUS     - Mid-range, additional features  
- J-Link PRO      - Professional, high-speed
- J-Link ULTRA+   - Highest performance, streaming trace

Technical Specifications

1
2
3
4
5
6
J-Link PRO Specifications:
- Max Speed: 50 MHz (SWD), 25 MHz (JTAG)
- Voltage: 1.2V - 5V target support
- Current: Up to 400mA target power
- Trace: 4-bit ETM, SWO, unlimited flash breakpoints
- Interfaces: USB 2.0 Hi-Speed, Ethernet (PRO models)

Advanced Features

1
2
3
4
5
6
// J-Link specific features
- Real-time terminal (RTT)
- Flash programming algorithms
- Unlimited software breakpoints
- Live debugging capabilities
- Production programming

Use Cases

  • Professional embedded development
  • High-performance debugging requirements
  • Production programming
  • Real-time trace analysis
  • Multi-core debugging

Advantages

  • Exceptional performance and reliability
  • Comprehensive MCU support (6000+ devices)
  • Advanced debugging features
  • Excellent toolchain integration
  • Professional support and documentation

Disadvantages

  • Higher cost compared to alternatives
  • Proprietary solution
  • Overkill for simple projects
  • Requires licensing for commercial use

ST-Link is STMicroelectronics’ debug probe for STM32 microcontrollers.

Product Variants

1
2
3
4
5
ST-Link Models:
- ST-Link/V2      - Basic debugging, older generation
- ST-Link/V3SET   - Latest generation, high-performance
- ST-Link/V3MINI  - Compact version
- ST-Link/V3MODS  - Modular system

Technical Specifications

1
2
3
4
5
ST-Link/V3SET Specifications:
- Max Speed: 50 MHz (SWD), 25 MHz (JTAG)  
- Voltage: 1.65V - 3.6V target support
- Interfaces: USB 2.0, Virtual COM port
- Trace: SWO support, bridge functionality

STM32-Specific Features

1
2
3
4
5
6
// ST-Link optimizations
- STM32 flash algorithms
- Option byte programming
- STM32CubeProgrammer integration
- Mass storage bootloader mode
- Drag-and-drop programming

Use Cases

  • STM32 microcontroller development
  • Educational and hobbyist projects
  • Cost-sensitive applications
  • STM32 ecosystem integration
  • Quick prototyping

Advantages

  • Excellent STM32 integration
  • Cost-effective solution
  • Good performance for STM32 targets
  • Wide availability
  • Integrated into ST development boards

Disadvantages

  • Limited to STM32 family (primarily)
  • Fewer advanced features than J-Link
  • Less robust for production use
  • Limited third-party MCU support
  • Occasional reliability issues

DAPLink is ARM’s open-source implementation of CMSIS-DAP.

Architecture

1
2
3
4
5
6
DAPLink Components:
- Interface MCU (typically ARM Cortex-M0+)  
- CMSIS-DAP firmware
- USB interface
- Target connection (SWD/JTAG)
- Optional: Virtual COM port, Mass storage

Common Implementations

1
2
3
4
5
Popular DAPLink Boards:
- mbed HDK         - Reference design
- PyOCD            - Python-based implementation  
- OpenOCD          - Open source debug solution
- Custom adapters  - DIY implementations

Configuration Example

1
2
3
4
5
6
// DAPLink configuration
#define DAP_SWD              1    // SWD protocol support
#define DAP_JTAG             1    // JTAG protocol support  
#define DAP_UART             1    // Virtual COM port
#define DAP_VENDOR_ID        0x0D28
#define DAP_PRODUCT_ID       0x0204

Use Cases

  • Open-source projects
  • Custom debugger solutions
  • Educational environments
  • Budget-conscious development
  • Platform independence requirements

Advantages

  • Open source and customizable
  • Low cost implementation
  • Cross-platform support
  • Standard CMSIS-DAP interface
  • Community-driven development

Disadvantages

  • Basic feature set
  • Limited performance compared to commercial solutions
  • May require technical expertise for setup
  • Less comprehensive MCU support
  • Limited professional support

Debug Interface Comparison

Performance Comparison

FeatureJTAGSWDCMSIS-DAP
Pin Count4-52-32-3 (via SWD/JTAG)
Max Speed25 MHz50 MHzVariable
Multi-deviceYesNoNo
PowerHigherLowerVariable
ComplexityHighMediumLow

Debugger Hardware Comparison

DebuggerPrice RangePerformanceMCU SupportUse Case
J-Link$400-2000+Excellent6000+Professional
ST-Link$20-100GoodSTM32 focusSTM32 development
DAPLink$10-50BasicARM CortexOpen source/Education

Practical Implementation

SWD Connection Example

1
2
3
4
5
6
7
8
Target MCU          Debugger
-----------         ----------
VCC     <---------> VCC (3.3V)
GND     <---------> GND
SWDIO   <---------> SWDIO
SWCLK   <---------> SWCLK  
RESET   <---------> RESET (optional)
SWO     <---------> SWO (optional, for trace)

JTAG Connection Example

1
2
3
4
5
6
7
8
9
Target MCU          Debugger  
-----------         ----------
VCC     <---------> VCC
GND     <---------> GND
TDI     <---------> TDI
TDO     <---------> TDO
TCK     <---------> TCK
TMS     <---------> TMS
TRST    <---------> TRST (optional)

Debug Session Workflow

1
2
3
4
5
6
7
8
9
10
11
// Typical debugging session
1. Initialize debugger connection
2. Detect and identify target MCU
3. Halt target processor
4. Download program to flash/RAM
5. Set breakpoints and watchpoints  
6. Start program execution
7. Handle debug events (breakpoints, exceptions)
8. Inspect variables and memory
9. Step through code execution
10. Reset or disconnect

Advanced Debugging Features

Real-Time Trace

1
2
3
4
5
6
// ETM (Embedded Trace Macrocell) setup
- Instruction trace capture
- Data trace monitoring  
- Performance analysis
- Code coverage measurement
- Statistical profiling

Serial Wire Output (SWO)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// SWO trace implementation
void swo_init(uint32_t frequency) {
    // Configure SWO pin
    CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
    ITM->LAR = 0xC5ACCE55;
    ITM->TER = 1;
    ITM->TPR = 0;
    ITM->TCR = ITM_TCR_ITMENA_Msk;
    TPI->SPPR = 2; // NRZ protocol
    TPI->ACPR = (SystemCoreClock / frequency) - 1;
}

void swo_print(const char* str) {
    while (*str) {
        ITM_SendChar(*str++);
    }
}

Breakpoint Types

1
2
3
4
5
6
7
8
// Hardware breakpoints
typedef enum {
    BREAKPOINT_HW_CODE,     // Instruction breakpoint
    BREAKPOINT_HW_DATA_R,   // Data read watchpoint  
    BREAKPOINT_HW_DATA_W,   // Data write watchpoint
    BREAKPOINT_HW_DATA_RW,  // Data read/write watchpoint
    BREAKPOINT_SW_CODE      // Software breakpoint (BKPT instruction)
} breakpoint_type_t;

Selection Guidelines

Choosing Debug Interface

Use JTAG when:

  • Working with complex SoCs or FPGAs
  • Need boundary scan testing
  • Require multi-device debugging
  • Production testing requirements

Use SWD when:

  • Debugging ARM Cortex processors
  • Pin count is constrained
  • Need high-speed debugging
  • Power consumption is critical

Use CMSIS-DAP when:

  • Want vendor independence
  • Need cross-platform support
  • Budget constraints exist
  • Open-source tools preferred

Troubleshooting Common Issues

Connection Problems

1
2
3
4
5
6
7
8
9
10
11
12
# Check connections
- Verify power supply (correct voltage)
- Check ground connections  
- Confirm signal integrity
- Test cable continuity
- Verify target MCU is not in reset

# Debug adapter issues
- Update firmware/drivers
- Check USB connection
- Verify debugger power LED
- Test with known-good target

Performance Issues

1
2
3
4
5
6
// Optimize debug speed
- Reduce debug clock frequency
- Disable unnecessary trace features
- Use appropriate debug protocol
- Check target MCU capabilities
- Verify signal integrity at high speeds

Programming Failures

1
2
3
4
5
6
// Flash programming troubleshooting
- Verify flash algorithm compatibility
- Check sector erase operations
- Confirm adequate target power
- Test with smaller program sizes
- Validate memory map settings

Emerging Technologies

  • USB4/Thunderbolt: Higher bandwidth debug connections
  • Wireless Debugging: Wi-Fi and Bluetooth-based solutions
  • AI-Assisted Debugging: Intelligent breakpoint placement
  • Cloud-Based Debugging: Remote debugging capabilities

Protocol Evolution

  • JTAG 2.0: Enhanced performance and features
  • SWD Extensions: Additional trace capabilities
  • Security Integration: Secure debug authentication

Conclusion

The choice of debug interface and hardware significantly impacts embedded development efficiency. JTAG provides universal compatibility and robust multi-device support, while SWD offers ARM-optimized performance with minimal pin requirements. CMSIS-DAP enables vendor-neutral solutions at the cost of some advanced features.

For hardware selection, J-Link excels in professional environments requiring maximum performance and features, ST-Link provides excellent value for STM32 development, and DAPLink offers open-source flexibility for custom applications.

Success in embedded debugging requires understanding both the technical capabilities and practical limitations of each solution, allowing developers to choose the optimal combination for their specific requirements and constraints.

This post is licensed under CC BY 4.0 by the author.