What is your best microcontroller code debugging strategy?

Start from a proper build system, which lets you easily switch to a Debug build. Use modern tooling. Segger + Ozone are my go-to. If you're using an RTOS, step 1 after the initial "blinky" is bringing up your RTOS awareness plugin/analyzer. Design your EVM's to have standard, high-quality debug connectors, without hand-wired adapters. And add ETM trace from the beginning. And all test point hooks, to quickly get a Saleae on it to see what is really going on. Adopt googletest for on-host tests. Write your library code to be pure C, so it can be heavily debugged without hardware. Then add your on-host unit tests to CI.

Debugging code on microcontrollers demands a versatile toolkit of strategies and techniques, as traditional debugging tools are often limited or absent in such constrained environments. Serial communication : Log messages using UART/SPI/I2C etc... LEDs, & GPIO pins: Use LEDs or GPIO) pins to provide visual feedback about the program's state Hardware debuggers(JTags/ST-Link etc) GDB on Linux error handling messages in code unit testing breaking code into small pieces and testing These are all valuable methods for identifying and addressing issues in microcontroller code. We also need to have patience(takes a lot of time) and adeep understanding of both the software and hardware aspects of the microcontroller's architecture(Data sheets).

There may be situations where either the right tool is not an option or not available in the moment. In a pinch, you can still extract variable values and system states using on board LEDs. You can do this by instrumenting your code to flash or toggle an LED at certain times to represent state. With multiple LEDs, you can also set the LEDs to represent binary values. Don't forget to also take advantage of different colors if your LEDs are RGB. These types of signalling don't only need to be used in a pinch. Many of these tactics can also be beneficial as the designed behavior of a product to help gather information from customers or colleagues

First, to make a complete project knowing everything about it, you need all these tools. These days, there are many tools more cheaper and affordable, also there is the AI tools like Flux, that can sure you the proccess of your circuit.

I've liked JTAG a lot for debugging embedded systems. I like using a very fast, asynchronous, interface. This allows GDB to be used with a graphical display. Displaying the web of data structures the are using in the Linux kernel.

printf() is the most convenient debug tool. For new platform bring up, enable a UART with debug message print out is the very first step. Once you have the tool, you can get 90% of project done.

Use dedicated internal peripheral (e.g. SWDIO) to log messages with various levels of severity (debug, info, warning, error, critical). Use embedded trace capability to profile code in real time

Commenting code is always a great way to document your intent or clarify anything that would be considered non-trivial. Print statements are also great so long as you are emitting useful information and the right amount of information.

Implement a logging and debugging framework in your code to print relevant information to a debug console or log file. Use different log levels (info, warning, error) for various types of messages.

Indeed printf() is quite useful for debugging, but need to consider implications of a generic printf(): - footprint (do you need/want complete support for '%g' if all you want is '%x' formatting?) - affect execution timing(if printf doesn't return until after resultant string is sent out a serial port). You may want to consider a public domain implementation of printf that you can tailor to your needs, and to minimize execution timing implement a FIFO and ISR that marshals data from printf to the serial port. If you configure the FIFO correctly, if a crash occurs at any point of execution, on reset inspect the FIFO and dump out any remaining data.

The best technique to debug code is to write it properly first. Most programmers write procedures/functions which are too large and too complex. "Modularity" is just a start. Code should be easy to read and understand; code should be written so it is easy to test.

I agree with this. Using a modular and abstracted approach is beneficial for testability, design, and portability of your code.

Sometimes with parallel operations and shared resources it is not always obvious in what context a variable is being manipulated. In this case, you can also use data watchpoints to pause on code when a specific variable or address is modified.

Breakpoints allow to pause code execution at specific points in the program and is helpful for isolating issues in complex loops or conditionals. Watchpoints, on the other hand, let you monitor the value of a variable or memory location in real-time, triggering a pause in execution when certain conditions are met. Combining these techniques with comments and print statements gives deeper insights into code's behavior and streamlines the debugging process.

I tend to write very simple applications, so debugging by print statements to a console is the easiest. I code in small steps, add a bit of functionality, then test it. Occasionally, or if I've made big changes to implement something (generally a sign of lack of forethought, but can just be down to hitting a wall) then I carry out ad-hoc regression tests too. Then back up the latest version either in VCS or more commonly as a numbered copy so I can backtrack if I break something next iteration. You never know: it might be the hardware.

Indeed, coding mistakes are mostly sw bugs due to design/requirements/coding-mistakes, rarely due to microcontroller or embedded environment. This also means, most of the code can be written using stub-interfaces which can return known data and help unit-tested using your favorite IDE and host toolchain to speed up the development and faster deployment. Sometimes it helps to do the sw development using micro-controller, mainly to make your own understanding of the limitations of environments. However, once developer understand the constraints, using host environment can speed things on day to day development, testing before deployment on microcontroller code.

I agree, having the debug UART with printf() statements after the blink LED samples is a great step. If you're using a medium-to-larger (internal SRAM/flash) microcontroller, then progressing to a mini-monitor program is really helpful in testing hardware with uploadable applets (SREC, ihex or plain binary) and a _run_ command. u-boot is good, but Ed Sutter's umon is better, with good examples of various device drivers, and even basic ethernet. (After many years of developing for microcontrollers, I tend to code the core command-line interface from memory, implementing read/write mem locations, load binary and run commands, along with some GPIO binary ops).

Coders are excellent at understanding and coding THEIR modules. Where I’ve primarily seen bugs crop up in my whole career is in the interactions between modules, either due to misunderstandings about how interfaces should be used (preconditions, parametric types or limits, postconditions), or (especially in embedded systems) due to interleaving of execution in nominally-independent work. Many misunderstand design of/with: critical sections, task priorities and blocking, memory sharing, etc. Careful planning and diagramming prior to coding can better ensure design correctness, lightweight regression testing can ensure drift from correctness is small and quickly caught—so that the need for debug is minimal.

Using debug UART and sending debug logs over it to debug specific functionality can be one of the useful debug technique. One can also pass dummy arguments as a input through UART which will act as a trigger source to some functionality.

The previous suggestions are all great. They are exactly what we teach in school. It's also all the things that are commonly listed as approaches to fixing issues in embedded code. The truth is that it's not an easy task, ever. Limited resources, slow or no I/O for logging. Debuggers, when available can help. In my experience single stepping code in debuggers is only useful for finding invalid compilation optimizations and initial bring up before your main code works. The startup code for most microcontrollers is well debugged, and rarely needs attention now. Over the years, the truth I've discovered is to avoid debugging on the target at all costs. Write simple code, less lines means less bugs to find. Write provably correct code.

Use version control right from the beginning. You can use version 0.1, 0.2, 0.3, for development releases, then switch to version 1.0, 1.1, 1.2, for production releases. Every time you write a new class, or group of related functions, module test it. When the module works, check it in. Later, if regression testing shows a problem, you can test individual versions to see when the problem was introduced. The error should be in the changes in that release.