The Bits and Bytes of Debuggers
For embedded device engineers, programmers/debuggers are essential tools of the trade. There are ways to get around using a debugger, but for anything beyond the most simple projects, it’s just not feasible to blink an LED for feedback.
Debuggers allow you to view the state of memory, the location of the instruction pointer, and more. But with the huge number of debuggers available, how do you choose the best one to use?
What’s inside a debugger, anyway?
Debuggers are themselves embedded devices. Inside a debugger is usually a microcontroller, often a USB interface chip, plus some level shifting and buffering chips. That’s it! Modern debuggers are as simple as they can possibly be to get the job done.
Debuggers were once known as “in-circuit emulators” or ICE. This is because early microcontrollers did not have on-chip debugging capabilities, so all the information about memory state, program counter, and I/O had to be skimmed off of the bus by another system. This usually took the form of a plug that would be inserted into the board in place of the microcontroller or microprocessor. All the signals would be taken out to a separate machine for analysis.
ICEs could be large, power-hungry and a pain to use, but they were the tool of choice during the birth of the microprocessor age. They typically offered extra features such as logic analyzers as well as advanced triggering and breakpoint capability.
The concept has remained the same, even as emulators and debuggers shrank to the tiny size they are now — all the address and data lines need to be skimmed and examined to see the state of the bus. Modern microcontrollers now have an on-chip debugging subsystem, and this subsystem communicates with your debugger via a serial protocol. This means that entire ICE in the above picture now fits on a tiny section of the microcontroller’s die!
About JTAG
Most microcontroller manufacturers have their own protocols, but the industry standard is JTAG, short for Joint Test Action Group. They are the standards body that defined the protocol, which was optimized for assembly-line testing. JTAG is able to, in many cases, completely replace slower and more expensive bed-of-nails testers. Luckily for us, this powerful protocol has trickled down into development programmers as well, enabling real-time information on processor registers, RAM state, watched variables, and more. Many chips support both the manufacturers’ proprietary protocol as well as JTAG, and using JTAG if it is available is usually the best option.
Microcontroller chosen, now what?
Do you buy the manufacturer’s programmer, or go with a third-party tool like a Segger J-LINK or Keil uLinkPro? The manufacturer’s programmers will be much less expensive than professional tools like the J-LINK, but they will have fewer capabilities and are locked to using only that manufacturer’s chips.
Base-level programmers start at under $30, with the extremely popular PICkit 3, for example, selling for about $50.
Many of the lower-end programmers are just that — programmers without any debugging features. Manufacturers also make more advanced debuggers, such as Microchip’s ICD3/4 or Texas Instrument’s MSP-FET. These have much more extensive features, including more breakpoints, much faster programming and debugging (sometimes orders of magnitude faster!), and they typically also support JTAG. If you need reliability and spend extended periods of time debugging, it is always worth upgrading to the higher-end proprietary tools or even shelling out the money for a third party tool. Third party tools also typically have better customer service if you run into problems. If you’re just hacking together a prototype, then the cheaper programmers are slower but they get the job done. I have a bunch of them floating around my workbench, and they do the brunt of my programming work. However, when serious bugs pop up (and they always do), I always reach for my ICD3, because the advanced debugging features will save you so much time and stress.
If you need to justify purchasing a more expensive debugger, it’s important to stress that last point — they will help speed up the debugging process, and make problem solving more effective. Also, the lower-end tools are explicitly not designed for production environments, and the companies will not offer support for these use cases. The higher-end tools have always inspired more confidence in me personally, as I’ve never had one fail. When you are in the middle of a 1AM debugging session before a critical deadline, you do not want your tools failing!
“ If you need a machine and don’t buy it, then you will ultimately find that you have paid for it and don’t have it.” — Henry Ford.
This is true with any set of tools, and especially so with digital tools. You can buy it cheaply, or you can buy it once.
