Debugging ARM Cortex-M1 processors implemented on Altera FPGAs can be challenging due to the complexity of the hardware and software integration. However, with the right tools and techniques, engineers can effectively debug their Cortex-M1 designs on Altera FPGAs to isolate and fix issues.
Use the Cortex Debug Connector
The Cortex Debug Connector provided by ARM allows debugging Cortex-M1 cores via a JTAG interface. This is implemented as a wrapper around the Cortex-M1 core and handles the JTAG communication protocol. The JTAG interface can be connected to a debugger or emulation hardware to control execution and inspect processor state.
For Altera FPGAs specifically, the SignalTap logic analyzer built into the Quartus design software is very useful for tapping signals in the Cortex Debug Connector block. This allows tracing execution, monitoring interrupts, capturing data values, etc. without needing extra hardware.
Leverage Debugging Hardware
For more advanced debugging capabilities, dedicated JTAG debug hardware can be used. The Segger J-Link debug probes are a popular choice, connecting to the Cortex Debug Connector via the JTAG interface. J-Link provides robust debugging software for runtime control, breakpoints, watchpoints, and data inspection.
More advanced options include emulators like the Segger J-Trace PRO which offer real-time code profiling. This helps identify hotspots and optimization opportunities in the Cortex-M1 software. Other emulators like the IAR I-jet provide trace capabilities for reconstructing program flow after the fact.
Use Debug Builds of Cortex-M1 Software
Having debug symbols and no optimizations in the Cortex-M1 software build is extremely useful for stepping through code and inspecting variables. Ensure the compiler toolchain generates debugging information and disables optimizations that can make debugging confusing.
For the ARM compiler in particular, debugging information can be enabled using the “-g” option. Compiler optimizations can be disabled using “-O0”. Enabling “Verbose Assembler” under debugging options helps match source code to generated assembly which is key for debugging.
Understand Cortex-M1 Debug Modes
The Cortex-M1 core has two basic debug modes – Halt mode and Monitor mode. Halt mode stops core execution allowing register and memory inspection. Monitor mode allows real-time debugging while the core continues executing.
Halt mode is blocking but gives complete control. Monitor mode is non-blocking, but care must be taken to step through code correctly and set breakpoints to avoid affecting the real-time behavior.
Choosing the right mode is important for bug reproduction. Halt mode can identify bugs that require stopping the system. Monitor mode is better for catching issues in the actual real-time environment.
Print Debug Messages
Sometimes there’s no substitute for good old fashioned print statement debugging. Print messages to a console or log can provide visibility into program flow, key data values, and other state information.
For Cortex-M1 systems, the simplest approach is to implement UART serial output and add print statements using the standard C library. More advanced systems may log to on-chip memory or dedicated debug hardware.
Be judicious in adding debug prints, as they can affect timing. But used properly, they can provide invaluable visibility without requiring extra tools.
Use Testbenches and Simulation
Don’t underestimate software simulation for debugging! Simulating the Cortex-M1 hardware design and running software via testbenches can identify many system-level integration issues long before running on the real FPGA.
QuestaSIM, ModelSim, and other simulators work very well for simulating a Cortex-M1 Altera FPGA design. Some additional debug features may be needed to fully model the final system, but fast software iteration is possible.
Simulation enables complete control and visibility for debugging. It’s invaluable for software development before running on often hard-to-debug hardware.
Debug Common Issues
Some common issues that appear when debugging Cortex-M1 on Altera FPGAs include:
- Processor reset not occurring properly
- Exceptions or interrupts not firing as expected
- Timing-related bugs due to FPGA resource utilization
- JTAG communication failures
- Memory map mismatches between hardware and software
Thoroughly verifying the reset sequence, interrupt handling, timing closure, JTAG hookup, memory maps, and other aspects of the Cortex-M1 hardware integration can avoid lots of common bugs.
Leverage Available Reference Designs
Rather than developing a Cortex-M1 design from scratch, starting from a known good reference design can avoid many debugging pitfalls.
ARM and Altera provide reference designs for Cortex-M1 soft cores on Altera FPGAs that are already tested. These can be great starting points for SoC integration, reducing the chance of hard-to-find bugs.
Reference designs also provide sample testbenches, demo software, and debugging hooks needed to kickstart development and debugging.
Conclusion
Debugging complex hardware-software systems like Cortex-M1 processors on FPGAs can certainly be challenging. But by using the right tools and techniques, following robust design practices, and verifying each step of integration, engineers can hunt down bugs and get their design working properly.
Leveraging FPGA built-in tools like SignalTap for logic analyzing, debug hardware like J-Link probes, debug builds of software, simulation testbenches, and available reference designs, most integration and firmware debugging issues can be solved through diligent engineering effort.
With an understanding of common debugging challenges and a systematic methodology, even the most troublesome bugs in Cortex-M1 FPGA systems can be squashed to produce a successful product.
