The debugger is arguably one of the most important tools available to embedded software engineers. The debugger is capable of not only loading firmware on a microcontroller but can peer into the depths of memory and registers, revealing its inner workings. Despite the debuggers importance, many developers overlook some of the most useful features of a debugger and instead settle for a trivial understanding of what a debugger can truly accomplish.
Many developers hold the misconception that all debuggers are created equal which results in many developers settling for the cheapest debugger that money can buy. Engineers will spend thousands of dollars on oscilloscopes and other tools but as soon as a debugger is in the picture one hundred dollars is too much spend. The debugger of choice is the free, feature limited version that ships with low cost development kits. A professional debugger can do so much more for developers than simply load code.
First, a good debugger can decrease development time. Really? Absolutely! Consider the fact that many of the low cost debuggers put limitations on the clock frequency that can be used to communicate with the target processor. Clock speed may seem like a minor detail but contemplate how many times during the development cycle firmware is modified and reloaded onto the system. The total time may not add up to a number one might consider significant but consider the responsiveness of the system when the application is running as well. Precious time lost at every turn.
A second feature of a debugger that also is under utilized is the ability to have more than two break-points. Many developers using low grade tools spend far too much time enabling and disabling break-points. Debugging an average bug often feels like a minimum of five break-points are required but rather than setting those breakpoints and digging into the problem, an engineer must set them, enable two, hit the breakpoint and then disable one so that the next breakpoint can be enabled. Over the course of a project one might wonder how many dollars and minutes are wasted to save $500.
One of the coolest features that many modern debuggers are beginning to add to their arsenal is the ability to monitor a microcontroller or embedded systems energy usage. Manufacturers are adding tools to help minimize energy usage by including an analog to digital channel that can sample an external shunt. The measurement of the shunt is performed at the same time that the program counter of the application is recorded which results in providing developers with an energy profile correlated to the function or program statement that is executing at that time. Developers can then focus on those areas in firmware for energy optimization.
The debugger can also be used to log and export application symbols as the application code executes. The debugger is able to record the values stored in memory for later examination and if desired, they can be plotted in real-time. The result is that a developer can create a visual representation of how the system is responding and behaving. The ability to plot the internal behavior of the application can be critical to discovering bugs or simply verifying the operation of the system.
Some debuggers may even have the ability to perform its standard debug features while at the same time providing an interface for third party software to sniff or control the debugger. A developer may have specific information they are interested in observing or monitoring that isn’t supported by the IDE’s interface to the debugger. Software development kits (SDKs) exist for many professional debuggers that allow the engineer to customize and develop their own software tools that can then be used to automate and/or test their embedded system.
Unfortunately, many developers never get to experience the speed and ease at which these features can help them develop their embedded system. Developers get stuck in a rut of fighting with two break-points and the bare minimum of features. The most capable and expensive debuggers don’t cost more than the overhead of one senior engineer for one day. So why do engineers torture themselves with a minimum set of features when powerful tools are so close at hand?
