Debugging an embedded system can be difficult when you’re dealing with either a simple system with few pins or a complex system with nearly every pin in use. Stuart Ball provides some tips to make debugging such systems a little easier.
Debugging a microcontroller system can be difficult. Things don’t work right and it often isn’t even clear why. Was something initialized wrong? Is it a timing issue? Is there conflicting use of shared resources?
Debugging is more complicated when there are limited resources. If all the processor pins are used, what do you connect to? How do you get debug information out of the firmware so you can see what is going on?
This article isn’t about debugging when you have Ethernet, USB, and Bluetooth interfaces available, or when you have a full-speed emulator. This is about debugging when there aren’t many resources available—simple systems with few pins, or more complex systems with nearly every pin already used for something.
Figure 1: This is the schematic for a serial port RS-232 driver. It’s a standardized circuit that plugs into a header on the board to be debugged.
Postmortem vs. Real-Time Debugging
There are two general ways of debugging an embedded system. One is postmortem, looking at the state of the system after it has failed or after it has stopped at a breakpoint. The other is real-time, debugging while the system is running. Each has its own place and its own set of challenges.
— ADVERTISMENT—
—Advertise Here—Generally, the two methods use different debug techniques. A postmortem debug happens when the motor is stalled, the software can’t recover, and you have no idea why it happened. You want to know the system’s state and how it got there. Setting breakpoints is a method used in postmortem debugging; you stop the system and look at the static state after a particular point in the code is reached.
Real-time or active debugging is more appropriate for looking at timing issues, missed interrupts, cumulative latency issues, and cases where the system just does occasionally does something strange but doesn’t actually stop. Real-time debug can tell you how the system got into the state that you are trying to analyze using postmortem methods. If you can capture enough information while the system is running, you have a chance to turn a real-time problem into a simpler static post-mortem analysis.
This article appears in Circuit Cellar 312, July 2016. Download the complete article.Universal Debug Solution
An asynchronous serial port may be the most common debug tool used in the embedded world. Most microcontrollers have at least one serial port built in. The serial port has limitations. Its speed is limited and it requires level translation to connect it to the RS-232 voltage levels of a PC.
In many cases, you might not want to put the RS-232 driver on your board. You don’t want to use the space required by either the IC or the RS-232 connector, especially for something that is only used while debugging. One way I’ve solved this problem is shown in Figure 1, which depicts just a Maxim Integrated (or Texas Instruments) MAX3232 RS-232 driver IC connected to a DE9 connector. The other side connects to a four-pin header. This is connected via a cable to the embedded system to be tested. This allows the embedded system to have just the four-pin connector wired to the microcontroller serial port pins, power, and ground.
You plug in the external circuit when you need to debug and unplug it when you are done. There is nothing special about this circuit, it is exactly the same as you might put on your microcontroller board. Except you don’t need the space on your board for this. The circuit takes power from the microcontroller board via pins 1 and 4 of the four-pin Molex connector. The connector indicated is polarized so you can’t plug it in backward. I’ve standardized on this in my embedded systems at least where the serial port is used for debug or download.
Although I used a connector with 0.1” centers on the interface board, there is nothing to prevent you from using a 2 mm or 0.05” connector, or even a row of pads at the edge of the board being debugged. You just have to make a cable that has the Molex connector at one end and whatever you need to match your embedded board at the other end. You can keep the driver board in your toolbox, put the connector on your embedded system boards, and you have it when you need it.
You can house the board into a plastic project box. In one case, I built one on a narrow piece of perforated project board, and covered the entire thing in heat shrink tubing. It has the right-angle Molex connector on one end, and a short cable with the RS-232 connector on the other end. I keep that one in my desk drawer at work.
— ADVERTISMENT—
—Advertise Here—
Circuit Cellar's editorial team comprises professional engineers, technical editors, and digital media specialists. You can reach the Editorial Department at editorial@circuitcellar.com, @circuitcellar, and facebook.com/circuitcellar
