Troubleshooting real-time software issues using a logic analyzer
Logic analyzer
A logic analyzer is a hardware test instrument that is used to monitor digital signals. Typical logic analyzers have anywhere from 32 to hundreds of digital channels. For software debugging, we generally only need 16 to 24 channels, and speeds under 100 MHz. So there is no need to get high speed or maximum number of channels.
The lower-cost analyzers can be obtained for under $500; they're simply a pod that plugs into the USB port of a PC, and software on the PC is used to visualize the captures. At the other extreme are some very powerful analyzers that can cost $20,000 or more. While the high-end analyzers have many attractive features that can speed up troubleshooting, a low-cost one is sufficient, at least for starters.
The one so-called luxury of a logic analyzer that is highly desirable is the memory depth. Memory depth represents how many samples can be stored in the logic analyzer before its memory fills up. For example, if sampling at 1 million samples per second, an analyzer with 32-K depth will fill up in just 32 ms, while an analyzer with 4-M depth can run for four seconds. The latter is extremely beneficial, because it allows you to watch the system, have a couple of seconds to manually trigger after you observe the failure, and know that the signals have been captured when the problem occurred. If you only have 32 ms, it's not possible to manually observe a failure, and thus it's more difficult to get the problem captured.
Other features that can be helpful but aren't necessary are good search filters, state machine triggers, and ability to compress captured data so that samples are only stored when the signals actually change, and thus longer traces can be obtained.
Every logic analyzer has at least two views for captured data, a timing view and a state view, as Figure 1 illustrates. The timing view is used to quickly visualize patterns, identify anomalies, and zoom in to points of interest in a data capture. The state view is primarily useful with more advanced troubleshooting, in which the data is downloaded to a PC and software is written to automatically parse the data and extra information such as execution time, checking for real-time deadline errors, and validating that no race conditions occurred. How to automatically parse a logic analyzer's data is a more advanced topic that I won't cover in this article.
Click on image to enlarge.
Hardware setup
To use a logic analyzer to troubleshoot software, you must connect it to the embedded system under test. Unfortunately, at least for existing hardware platforms, this is sometimes the biggest challenge.
The goal is to identify eight unused digital outputs from the embedded system that can be used to send codes from software to the logic analyzer. Sometimes this is easy. There might be an unused 8-bit digital I/O port that can be used for this function. In other cases, there might be eight spare pins, but because they're scattered on various I/O ports, they're not as easy to write to. Nevertheless, as long as they're free, that is good enough.
If there aren't at least eight available pins, you may need to scrounge for them. For example, suppose a system has an SD card, but the SD card is not used when the failure to be debugged happens. The command, clock, four data lines, card detect, and write protect lines can potentially all be used to provide 8 bits; they just need to be reconfigured in software.
If the target system has an FPGA (or CPLD), it may be possible to use eight pins from that device and send a command to the FPGA using whatever communication means already exists between those two devices, then allow the FGPA to output the digital signals.
The next challenge is to hook up these eight outputs to one of the ports on the logic analyzer. Most logic analyzer probes can connect directly to 0.1-inch pins and include clips that allow attaching onto smaller pins. If necessary, a hardware technician can add wires to the embedded system under test to bring out these eight lines in such a way that the logic analyzer can more easily be connected to it.
If the problem that needs to be debugged includes some kind of I/O, such as push-button keys, a controlled digital output, or a serial link, each of these signals should also be connected to other channels on the logic analyzer.
Figure 2 shows a block diagram of the setup. The I/O connections on channel 2 are optional.
When designing hardware for a new real-time embedded system, a design-for-test requirement should be to have eight dedicated digital output pins available specifically for software's use, and to have these brought out to a connector for easy connection to a logic analyzer. At InHand Electronics, we typically place a high-density connector on the board with all the signals that we may want to hook up to the logic analyzer for software debugging, so that board real estate used for software debugging is minimized. We have a separate break-out board populated with 0.1-inch pins for each signal that makes it easy to connect a logic analyzer. An example is shown in Figure 3; a cable is used to make the connection from the system under test to the breakout board.
Click on image to enlarge.
Once the hardware is setup, the next step is to define macros to output codes to the logic analyzer.
Loading comments... Write a comment