Debugging issues when porting the Cortex-M1 DesignStart project

Porting the Cortex-M1 DesignStart project to a new hardware platform can be challenging, with many potential issues arising during the debugging process. This article provides an overview of common debugging problems and solutions when porting the DesignStart project.

Issues with JTAG/SWD connectivity

One of the first issues that may arise is not being able to connect to the target Cortex-M1 chip via JTAG or SWD. Some potential causes and solutions include:

• Incorrect JTAG/SWD pin mappings – Double check the datasheet for your Cortex-M1 chip and verify the correct mappings between the debug probe and the chip.
• JTAG/SWD signals not brought out to pins – The JTAG/SWD signals like TCK, TMS, TDI, TDO need to be connected from the Cortex-M1 chip to header pins or a debug connector. Check your schematics.
• Incorrect JTAG/SWD voltage levels – Verify the voltage levels from the debug probe match what the chip expects, 1.8V or 3.3V being common.
• JTAG/SWD signals not properly terminated – Add resistors to terminate the JTAG/SWD lines as per recommendations in the Cortex-M1 user guide.
• Debug probe driver issue – Update to the latest version of the debug probe software/firmware and host drivers.

Cortex-M1 chip reset issues

The Cortex-M1 chip may fail to come out of reset, some things to try:

• Check reset signal from debug probe – Verify the reset line from the debug probe to the Cortex-M1 reset pin is connected properly.
• External reset circuit problems – Check any external reset button/logic connected to the chip reset pin.
• Power supply issue – Measure power rails under load, ensure supplies remain in valid range for Cortex-M1.
• Watchdog timer reset – The Cortex-M1 watchdog timer may be enabled and triggering before debugger attaches.
• Debug probe reset settings – Try tweaking reset pulse width and reset type settings in probe config.

Mapper and memory problems

The Cortex-M1 memory map may not match what the debugger expects, causing code to not run properly. Things to check:

• Flash/RAM sizes – Confirm the expected flash and RAM sizes match the actual sizes in your Cortex-M1 silicon.
• Memory remapping – Cortex-M chip memory remap registers may need configuring in your system code.
• Segmented flash – If using segmented flash, the linker script and debugger config need updating.
• External memories – Any external memories need to be configured correctly in both hardware and debugger.

Fault exceptions and hangs

The Cortex-M1 may end up in a fault exception or hang due to problems like:

• Stack/heap collisions – Check linker scripts, memory allocations and stack sizes for potential overlap.
• Undefined instructions – Enable undefined instruction trap debugging and check code.
• Waits and sleep modes – Ensure proper wake up from sleep/low power modes.
• Interrupt issues – Verify interrupt sources and handler code are correct.
• Fault checking errors – Enable fault checking/reporting in debugger to get details.

Peripheral/device issues

On-chip peripherals and external devices may not work properly due to:

• Clock configurations – Check that all peripheral and device clocks are enabled properly.
• Pin mappings – Verify peripheral/device pins are connected to proper Cortex-M1 I/O pins.
• Initialization code – Double check base addresses, interrupts and peripheral initialization code.
• Power/reset control – Ensure power and reset control signaling for peripherals/devices is correct.
• Timing issues – If using peripherals at higher speeds, look for timing problems.

Toolchain and compiler problems

Toolchain issues can cause code bugs and linker errors:

• Compiler version – Use a compiler version that officially supports the Cortex-M1.
• Compiler flags – Double check compiler flags, include paths and definitions.
• Linker scripts – Verify the linker script matches the Cortex-M1 memory map.
• Code generation – Compiler bugs are possible, try different optimization levels.
• Undefined symbols – Linker needs all used symbols defined, add missing libraries.

Middleware and library porting

Porting middleware and software libraries to the Cortex-M1 may require changes like:

• Target configuration – Update middleware configuration header for Cortex-M1 specifics.
• Initialize hardware – Modify to initialize Cortex-M1 hardware, clocks, pins, etc.
• Memory allocation – If statically allocated, may need to adjust for Cortex-M1 memory.
• Interrupts – Update interrupt number defines and handlers for Cortex-M1.
• Peripheral usage – Change to use Cortex-M1 on-chip peripherals.

DesignStart firmware porting

When porting the DesignStart firmware some specific things to watch for:

• Startup code – Modify for correct Cortex-M1 stack pointers and memory map.
• CMSIS usage – Update for the Cortex-M1 specific CMSIS definitions.
• SysTick setup – Configure SysTick timer for correct Cortex-M1 clock.
• Clock configs – Update clock settings for your Cortex-M1 silicon.
• Pin mappings – Change GPIO pin mappings to match your hardware.
• Example projects – Port any DesignStart example projects to your hardware.

Debugging early boot code

For problems in early Cortex-M1 boot:

• Start at reset vector – Set debugger to halt at reset vector before startup code runs.
• Single step – Step through startup code to find where it deviates from expected behavior.
• Monitor registers – Watch key registers like stack pointers and program counter for errant writes.
• Check memory writes – Verify vector table, .data and .bss writes occur as expected.
• Enable logging – Use debugger SWO to output logging for early boot failures.

Problems flashing via debug probe

If unable to flash Cortex-M1 firmware via the debug probe, try:

• Reduce flash speed – Lower debugger flash programming speed if reliability issues.
• Flash voltage – Increase target flash voltage during programming if possible.
• Flash partitioning – Adjust debugger flash partitioning to match hardware sectors.
• Flash dumps – Read back flash after programming to verify successful writes.
• Reset after flash – Issue a reset or power cycle after flash programming.
• Flash loader settings – Adjust flash loader algorithm settings if available.

Intermittent hard faults and crashes

For intermittent faults and crashes during debugging:

• Minimum project – Reduce to the simplest code to isolate the issue.
• Debug power – Use a separate power supply for debugging to minimize noise.
• Scope pins – Use an oscilloscope to look for noise or anomalies on interfaces.
• Reset sequence – Improve external reset circuitry and reset the chip before debugging.
• Timing – Increase wait times in code to fix race conditions or timing-sensitive bugs.
• Temperature – Run debugging at range of temperatures/voltages that may expose hidden bugs.

Debugging with optimized code

Debugging projects built with optimizations enabled can be difficult. Strategies include:

• Mixed optimization levels – Build files with different levels of optimization to isolate issues.
• Debug symbols – Ensure full debug symbol data available for source level debugging.
• Disable optimizations – Turn off specific problematic optimizations selectively.
• Debug friendly optimizations – Focus on optimizations that don’t impede debugability.
• Inspect assembly – Understand how optimized code differs from the original source.
• Function tracing – Trace function calls and reconstruct optimized code flow.

By understanding the common issues that can arise when porting the Cortex-M1 DesignStart project, developers can employ these debugging techniques and solutions to get their hardware platform working quickly and efficiently.