3 tips to reduce debugging time for embedded

Engineers like to solve problems. That's what we do. Unfortunately, one of the biggest problems embedded software engineers have is creating a lot of problems and then fixing them by spending a lot of time (debugging!) making themselves heroes. Companies with embedded software engineers spend 20% to 40% of their time debugging is common! Thankfully, teams can make many potential changes to reduce the amount of time they spend debugging and bring it down to single-digit percentages. This article will examine a few tips for reducing debugging time.

1 - Embrace Test-Driven Development (TDD)

Test-driven development is a technique that allows developers to build their production software incrementally, relying on tests to indicate the code they write. For example, TDD allows developers first to write a test case that fails and then write-only code that allows that test case to pass. The process is then repeated.

Traditionally, embedded software developers would write entire modules of code before testing. Writing thousands of lines of code in a few weeks is possible. So, when it comes time to test it if it doesn't work, what's the problem? God only knows! Developers must painstakingly review the code and find the problem and fix it. The time required to perform this operation can be considerable.

On the other hand, for developers using TDD, if an error occurs and a bug is injected into the code, the test case will tell the developer immediately! Since they are writing the code incrementally, they are more likely to know exactly what changes they have made and can fix the problem immediately. TDD seems to take more time to practice, but it creates a set of test cases that can be run in regression tests to ensure that everything is working as expected. TDD kills two birds with one stone: reducing debugging time and automating tests.

2 - Develop as many off-targets as possible

When a project starts, the first reaction of almost every embedded software developer is to get a development board and start writing embedded code. Unfortunately, in many cases, embedded code is not the differentiating factor of our product. It's the application code. While much of the application code will eventually need to interact with the hardware, many modules can be developed off-target, i.e., on the host computer.

Developing off-target code provides developers with many opportunities to reduce the time spent per debug cycle. For example, typically, to write and test code for a target microcontroller, developers must：

1.Cross-compile the code

2.Start a debug session

3.Program the device via SWD

4.Run the code on the target

Verify that the code works properly by running the code on the target (must also have all low-level code).

If the code was developed on the host, the developer must compile it for the host and then run the code being developed using a unit testing tool, emulator, or custom program. If problems are found, it is faster to fix, recompile and start over. On embedded targets, programming the target alone can add tens of seconds to each cycle, not to mention the temptation to execute the code in a single step.

Off-target development/debugging can produce specific errors. However, I now write about 75% of my code off-target and find that I am faster and more efficient. I can quickly force a problem in my code, determine the cause, fix it, and move on rather than tracking the problem through embedded targets. Of course, some things will appear on the target, not the host.

3 - Master the debugging strategy

The least efficient debugging method known to man is to debug lines of code in a single step. Don't get me wrong, there is a time and a place for it, but it tends to waste a lot of time. Unfortunately, embedded software developers use breakpoints and single-step debugging by default. To get better at debugging, developers must master other debugging strategies available on modern microcontrollers.

Today, there are at least eight different debugging techniques available to developers. These techniques, in order from simplest to most complex, include

Watch / Expressions: Provide developers with the ability to examine CPU and peripheral registers. They can typically monitor variables, perform calculations, or stop the CPU when changes are made.

Breakpoints: allow developers to stop CPU execution on a specific line of code. Advanced breakpoints can be used to set conditional statements.

Print: Provides the developer with the ability to print character data to a mapped serial interface. Depending on the implementation, this may or may not affect real-time performance.

Assertions: These are conditional statements used to verify assumptions at specific points in the program. Failed assertions typically stop the CPU and provide the file and line location of the failed assertion.

StatisTIcal Profiling: Periodic sampling of various registers in the application that occur simultaneously with its operation. This usually does not affect real-time performance. For example, one may want to sample the program counter (PC) to see what code modules are being executed.

Data Analysis: Periodic sampling of various memory locations containing variable data. Data analysis can be useful in conjunction with real-time visualization tools to monitor system state, changes in variables of interest, etc.

Task and Data Tracking: Enables developers to track events in real-time OS applications. As a result, developers can gain insight into application performance, task latency, runtime, and more.

Instruction tracking: Enables developers to record every instruction executed on the processor. This can be used to understand code coverage during testing, debug compiler issues, and more.

Having all these techniques and knowing when to use them can greatly reduce debugging time when defects enter the system.

Conclusion

A lot of time can be spent debugging embedded software. Sometimes, debugging time is unavoidable; however, developers may spend more time in many cases than they need to. We've explored several areas you can investigate further to reduce the time you and your team spend debugging. If you spend more than 20% of your time debugging, please take an hour this week to determine what changes you can start making immediately to control the time you spend debugging.