Embedded Serial Bus Debugging using Oscilloscopes

Introduction

In the electronics industry, the drive to reduce size, power, and cost of products is leading to an increased use of serial buses in embedded devices. While serial buses reduce pin counts, power consumption, and space required for data transmission, they also lead to greater design complexity. Engineers working with serial buses need a quick way to debug and validate their designs. The asynchronous nature of many serial standards presents a challenge to capture and decode. While protocol analyzers are great tools for finding functional and timing issues on serial buses, oscilloscopes also allow engineers to isolate sources of noise, capture transients, perform physical layer compliance tests, and measure power use. With built in serial trigger and decode, oscilloscopes become powerful all-in-one tools for embedded hardware engineers.

Capture and Decode

Before serial decoders were built into oscilloscopes, engineers would have to manually decode the serial frames by hand. This required a deep understanding of the serial bus specification and some luck when trying to capture a specific frame. In figure 1, I’ve captured one I2C frame on an oscilloscope with SCL (Serial Clock Line) on channel 1 and SDA (Serial Data Line) channel 2. To decode this by hand I had to use the following procedure.

1. Capture one frame on the oscilloscope.
2. Take a screenshot.
3. Open it on a computer and add lines on each rising edge of the clock.
4. Convert the SDA signal at each rising SCL edge to a 1 or 0 corresponding to the level of the signal.
5. Based on the I2C specification, convert the binary values to hexadecimal. By counting the clock edges and knowing that the I2C specification uses a start pulse, 7 address bits, a read or write bit, acknowledge bit, 8 data bits, another acknowledge, and finally a stop bit, I can figure out the hexadecimal values. In this case, this is a write frame with address 0x29, and 0x04 data.

This method works, but is time consuming and there’s a possibility that it’s not even the frame of interest. If an engineer needs to decode multiple serial frames, the time required becomes costly. This is where the benefit having serial decode and trigger built into oscilloscopes becomes obvious. In figure 2, I’ve turned on the built-in I2C decoder in the oscilloscope. Additionally, I’ve used the serial trigger capability to quickly find this exact packet of data. You can see the decoded frame in blue across the bottom of the oscilloscope graticule and the orange trigger point on top. Engineers can use this capability to quickly find the exact data of interest on the bus without needing an intimate knowledge of the serial specification.

Using Segmented Memory to Capture Infrequent Serial Events

Let’s say a design has multiple IC’s (integrated circuits) that communicate with a microcontroller via I2C and I want to see all the data that gets written to one specific IC. This can be done easily by setting up a trigger on the IC’s write address. This will set the scope to trigger anytime it sees that address, but it’s still difficult to get an overall view of the transmitted data from the single waveform display that oscilloscopes default to. This is a situation where segmented memory is very useful. Segmented memory will tell the oscilloscope to wait until the trigger condition is met, save the waveform to memory, time tag it, then rearm the trigger and wait for the next occurrence of the trigger.  In figure 3, I’ve set the oscilloscope to trigger every time data is written to the IC with address hex 64 and turned on segmented memory to capture 1000 occurrences. Using this tool, an engineer can see what data is being written to the IC, how often it is being written to, and view the physical signal for every frame. If one or more of the frames had unexpected data, the engineer could select that frame in the lister and check the integrity of the physical signal. Noise or a transient could have caused the error.

Figure 3: Serial Decode with Segmented Memory

Isolating coupled transients

Infrequent transients coupled onto a serial bus could cause errors or randomly reset an embedded processor. Using traditional oscilloscope triggering methods, they can be very hard to isolate. The presence of a digital serial signal, already with infrequent events, makes it even harder to trigger on the even more infrequent transient. One way to identify if a transient signal is present is to use infinite persistence. The infinite persistence setting will not clear the display between signal captures. The display will keep updating and overlaying the new signal on top of the previous signals. Using a serial trigger to show all transmitted frames and infinite persistence should result in a display with every bit position filled. If a transient is present, you will quickly notice it stand out.

Once you’ve identified that a transient is present, you’ll want to trigger on it. Like I’ve said previously, it can be very tricky to capture using traditional triggering methods. With the arrival of touchscreen oscilloscopes, a new triggering method became possible. Using a feature called Zone Trigger, capturing transients becomes trivial. Figure 4 shows a USB (Universal Serial Bus) signal with an infrequent transient.

To trigger on this transient, all I had to do was draw a box on the touchscreen and select Zone 1 Must Intersect. The oscilloscope was already triggering on any USB start of frame. Turning on Zone Trigger told the scope to only trigger when it saw a USB start of frame and a signal inside the designated area. This can be seen in figure 5. Once you’ve successfully triggered on the transient, you can perform measurements on it in order to figure out the source.

Finding noise sources

What if your serial bus is not experiencing random transients, but constant coupled noise instead? To figure out the source of the noise, a different approach must be used since you can’t trigger on noise. This is a great use of the oscilloscope’s FFT (Fast Fourier Transform) math function. The FFT converts the time domain signal to a frequency domain representation. This enables you to identify the frequency components of the coupled noise. Figure 6 shows a USB signal with coupled noise.

Just from this screenshot of one USB start of frame packet, I know that the noise has about a 150mV peak-to-peak voltage. In order to figure out the source of this noise, I use the FFT function and turn on peak markers. When I first turned on the FFT, I did not see a frequency component that stood out as the noise. This is an indication that the noise is a much lower frequency than the USB signal.

In order to find the main frequency component, I had to zoom out to 10ms per division. At this time base, the FFT is able to detect low frequencies. In figure 7, you can see that the noise is about 61Hz. This is actually noise coupled onto the USB signal from an AC power line in the United States.

Another common source of noise on embedded serial buses can be from clock signals running in the megahertz frequencies. Figure 8 shows an FFT running on a USB signal that has noise coupled from a 16MHz clock. Internet of things devices with built in wireless LAN may also experience noise from the radio. Figure 9 demonstrates a USB signal with a frequency peak at 2.4GHz, a common wireless LAN frequency.

Summary

Embedded hardware engineers are constantly challenged to create smaller, more power efficient, and lower cost devices. With this comes a greater need for more powerful debug and measurement solutions. Modern digital storage oscilloscopes with built in serial trigger and decode make excellent tools for the job. Decoding individual frames by hand is a thing of the past with built in decoding. Advanced serial triggering has made capturing exact frames of interest easier than ever before. Segmented memory can be combined with serial trigger and decode to capture many specific data transmissions over a long time period. New triggering techniques made possible by touchscreens make it trivial to isolate infrequent transients. Finally, sources of noise can be identified by using the oscilloscope’s FFT function. Embedded engineers have an entire toolbox of debug tools available when they have a modern oscilloscope on their bench.