Will code debugging / breakpoint still work with a custom routine? Arm Cortex M0

Yes, code debugging and breakpoints will still work when using a custom routine on an ARM Cortex M0 processor. The Cortex M0 includes dedicated debug circuitry that allows for halting execution at any instruction address, examining CPU and peripheral registers, and stepping through code. This functionality is independent of the code being executed.

Overview of Debug Features in Cortex M0

The Cortex M0 processor includes several key hardware features to enable debugging:

• Debug Access Port (DAP) – Allows a debug probe to access internal registers and debugging logic.
• Breakpoint Unit – Supports up to 2 hardware breakpoints that can halt execution on a specific instruction address.
• Debug Control Block – Contains debug configuration registers for controlling debug features.

These debug modules are always present and active, regardless of the software running on the Cortex M0 core. This means debug functionality is available even when using fully custom code without an OS or runtime environment.

Using Breakpoints with Custom Code

To set a breakpoint in your custom Cortex M0 code:

1. Connect a debug probe such as J-Link to your board’s SWD (Serial Wire Debug) header.
2. In your debugger software, locate the address of the instruction where you want to halt execution.
3. Configure one of the Cortex M0’s hardware breakpoints to trigger on that address.

When the processor reaches the breakpoint address, execution will halt. You can then examine register and memory values, single-step through instructions, and restart execution.

The Cortex M0 hardware breakpoints work identically whether you are debugging custom bare-metal code, vendor-provided demo code, or a commercial RTOS. The processor handles the breakpoint the same way in all cases.

Limitations of Cortex M0 Breakpoints

While full debugging is available with custom code, the Cortex M0 has some limitations compared to more advanced Cortex-M processors:

• Only 2 breakpoint registers – More complex software may require more simultaneous breakpoint addresses.
• No breakpoint on data access – Breakpoints only trigger on instruction fetches.
• No breakpoint mask registers – Breakpoints always trigger on an exact address match.

Despite these limitations, the Cortex M0 breakpoint unit covers the basic functionality needed for most debugging scenarios with custom software.

Using a Debug Agent with Custom Code

To enable debugging, you will need to use a debug probe with an agent that communicates over the Cortex M0’s DAP interface. Common choices include:

• J-Link – SEGGER’s proprietary debug probe and GDB server software.
• OpenOCD – Open source GDB server with support for many debug probes.
• pyOCD – Python GDB server using CMSIS-DAP standard.

These agents can be used for debugging both custom and vendor-provided software stacks. You configure them to connect to your specific debug probe hardware. The agent handles the target communication details, while presenting a standard GDB server interface to your host debugger.

Debugging Custom Code Without an OS

When debugging bare-metal code without an OS, you will need to manually start and initialize the debug agent. This typically involves:

1. Configuring debug probe connections and settings in agent config files.
2. Starting debug agent server on host machine.
3. Connecting from your IDE to the GDB server.
4. Issuing gdb commands to connect to the target and load symbols.

The exact steps depend on your debug hardware, agent, and IDE. But the process will be the same for your custom code as it is for vendor-provided examples.

Debugging With a Commercial RTOS

Commercial RTOSes like FreeRTOS typically include pre-configured debug agent connections. For example, STM32CubeIDE integrates J-Link and automatically connects to supported boards. The RTOS vendor handles setup details like:

• Starting the GDB server on host machine
• Connecting to board and loading symbols
• Providing IDE integration

This simplifies the debugging process when using an RTOS. But fundamentally the debug capabilities are the same for RTOS and custom code.

Tips for Effective Debugging

Here are some tips for smooth debugging with custom Cortex M0 code:

• Ensure reliable connections between debug probe, target board, and host machine.
• Verify debug probe drivers are installed and agent software is configured correctly.
• Generate and load debug symbols for your custom code.
• Use breakpoint addresses rather than file/line numbers.
• Single-step carefully and examine register/memory values.
• Have debug agent source code available in case target communication issues occur.

With good configuration and controlled stepping, the Cortex M0 debug features enable stable debugging even for bare-metal custom projects.

Conclusion

The ARM Cortex M0 includes dedicated debug hardware that enables breakpoint debugging and step execution regardless of the software environment. While the M0 has basic debug capabilities compared to newer Cortex-M processors, it provides the fundamental tools needed for debugging custom code.

With the use of a debug probe and agent like J-Link, OpenOCD, or pyOCD, developers can leverage these debug features to validate their custom Cortex M0 projects. The same procedure can be used for debugging vendor-provided code examples. So debug access is consistent across bare-metal and RTOS use cases.

By utilizing the Cortex M0 debug architecture and best practices, developers can have confidence debugging and validating their custom embedded software designs.