Five steps to serial joy

Top tips for getting good debug information out of serial buses.

Designers who use leading edge serial and narrow buses, such as HDMI for video connections and SATA for storage, know that oscilloscopes are good tools for compliance testing, margin analysis and performance validation. But embedded system designers tend to have a different attitude toward serial communication. Although high-performance buses like PCIe are used for critical communication tasks, almost all embedded designs also use buses like CAN, LIN, I2C, SPI, RS-232 and low-speed USB for wide variety of chip-to-chip communication tasks.

An embedded designer will choose these industry-standard serial buses for different reasons than the SATA designer. Utility, price, and ease of implementation are more important than leading-edge performance.

The testing requirements for these buses are also different. Interoperability and faithfulness to the standard may be less important; but the stability of the bus and the traffic that is flowing over it are critical. We don't want to spend time debugging a data pipe, but we do want to use the data on our bus.

In that spirit, I'll discuss several tips for improving the ability of your oscilloscope to analyse lower-speed serial buses. Some of them depend on certain scope features, but most of the techniques can be applied to generic scopes. In addition, it's possible that your current scope can be adapted to these tasks with little or no upgrading.

These techniques are useful when used individually; but they become most effective when combined. Experiment with the tools available to see what works best with your daily challenges.

Symbolic decoding

Older engineers will recall that oscilloscopes were sold with internal printers that were used to create strip charts. The charts were created from either one long, slow acquisition or many faster acquisitions - tape was an important lab tool. These strip charts would be taped to the wall of the lab, and the designer would then manually decode the meaning of the scope traces.

Going through strip charts is tedious and error prone. Another problem is that it's difficult to extrapolate to higher levels of abstraction. A waveform needs to be visualised as binary, then as a packet, as the packet contents, and then as the ASCII or symbolic meaning of the packet contents. Some can 'eyeball' the display, spotting patterns to get a feel for what is going on in their system. But even for them, brain cycles spent interpreting the display cannot be used for analysing their meaning within the system.

Modern digital oscilloscopes - even modestly-priced models - do this analysis internally. With a few seconds of configuration, you can be viewing read/write data, packet contents, and error codes. Some models can even perform this analysis in hardware so there is no impact on the scope's performance.

Use digital channels

Inter-chip and intra-system communication buses are usually only a small element of an embedded design. There are often D/A converters, A/D converters, sensors, displays, control loops, processers and electromechanical components that all must work in concert.

If your oscilloscope only has two or four channels, your low-speed serial buses can quickly consume all your debugging resources. This is where mixed-signal variants of oscilloscopes can come in handy.

Mixed-signal oscilloscopes combine analogue channels with a large number - at least 16 - digital channels. The big benefit in embedded system analysis is that you can allocate digital channels to serial bus timing and decoding - which leaves the scarce analogue channels free for time-synchronised analysis of other components. You may still want to use your analogue channels to verify the physical layer performance of your serial bus components; and then when you are done, switch to digital channels for a timing and protocol-layer view.

You can then measure the latency of events from sensor to processor to output. Or you can verify the arbitration of multiple inputs that are competing for bus resources.

Use counters

A counter is like a stethoscope for understanding the health of your bus. As with your arteries, your bus can get clogged up with the wrong data and the flow of the right data can be restricted. And like your heart, there can be anomalies that can be dangerous for the integrity of your entire system. Event counters can give you a quick status check of the traffic on your bus, to see whether some packet types are appearing unusually frequently.

With counter analysis, decoding performance is very important. The faster your oscilloscope processes serial traces, the sooner you can get statistically meaningful results. Remember, this is meant to be a quick test and not a lengthy analysis.

If your oscilloscope doesn't offer these counters, you can connect the Trigger Out port of your scope to an external counter. While it won't give you a full dashboard of bus performance, it will give you insight into how many times a particular triggering event occurs.

Use bus-specific triggers

Given enough triggering tools, most designers feel that they can find and solve any problem. Serial bus-specific hardware triggers are useful for many reasons. First, triggers make it easy to debug bus issues. Error triggers allow you to isolate events where the transmission fails. It's also easy to isolate frame start or stop transactions so bus latency can be measured.

Second, triggering on bus protocol or data values makes it easy to debug system-wide problems. For example, a hex data value can be assigned in software to represent an error condition - perhaps a buffer overrun or a sensor bias value that is too high. As the analogue, digital and serial signals are time-correlated, triggering on the error code can quickly lead to the cause of the problem.

Third, counter analysis can be improved with hardware triggers. You can isolate the exact events that matter to you. Plus, the bus counters run independently of the measurement counter. This means that not only can the absolute number of occurrences of an event be tracked, but the relative occurrence as a percentage of all packets can be estimated.

Use memory segmentation

Serial buses are an excellent example of a bursty signal. There are periods of activity followed by periods of dead time.

Even deep memory scopes can run out of acquisition memory in milliseconds. Fortunately, many oscilloscopes give you the ability to segment memory - to fill memory in fixed-width segments around an event of interest. This can dramatically increase the time that you can view in a single acquisition.

Even if every frame is captured, segmenting the acquisition memory will increase the length of time captured by the inverse of the duty cycle. For example, the capture time of a 25 per cent duty cycle bus will be increased four-fold.

Recent articles

Info Message

Our sites use cookies to support some functionality, and to collect anonymous user data.

Learn more about IET cookies and how to control them