Save. Share. Connect.
Saturday, June 25, 2016
VOLUME -24 NUMBER 12
Publication Date: 12/1/2009
Front Page News
People in the News
Electronic Mfg. Services
Electronic Mfg. Products
Special Features: Test and Measurement
Product Preview: productronica
December 2009 Issue
Add Message Board
Capturing and Troubleshooting Serial Data Signals
WaveSurfer model 104Xs-A 4-channel oscilloscope with 1GHz bandwidth amplifiers and 5 gigasample/sec sampling rate ADCs.
By Dr. Michael Lauterbach, LeCroy Corp., Chestnut Ridge, NY
Many chips and devices send information or are controlled by a serial data bus. Even if you are not designing the serial data path, you may end up testing the correct operation of your device by sending certain addresses or data values then checking for proper action. In recent years, a wide variety of serial data standards have come into use. Here, we will concentrate on using digital oscilloscopes for testing and troubleshooting some of the most popular low speed serial data protocols: I2C, SPI, RS-232 and generic UARTs. Many of the techniques also apply to other serial data protocols.
I2C (Inter Integrated Circuit) protocol is a multi-master bus providing arbitration and collision detection. It is fully addressable with an Ack handshake. There can be multiple masters and slaves in an I2C system each with a unique address code in 7 or 10 bit format. Typically, testing starts with examining the clock line to see that it has correct amplitude and timing. Once the clock is verified, the majority of the engineering work comes in testing the response of the device(s) to a variety of addresses and data values.
Multiple packets of I2C data are captured in the top trace. The table at the bottom lists the time of arrival of each packet relative to the trigger and various characteristics of each packet. The user can click on each line of the table to view a detailed zoom of that packet in the lower trace.
Today's digital oscilloscope can be equipped with a package specifically targeted to I2C testing, enabling it to capture both the clock and data signals, show the voltage vs. time traces on the screen, and decode and save the data packets. This is much faster and easier than the older method of looking at the screen of a 'scope and manually counting 1's and 0's then writing the decoded information in an engineer's notebook. Also, it is less subject to human error.
If the engineer wants to verify proper operation of a device in response to a particular command the 'scope can trigger when a specific address is sent on the bus or even when that address plus a specific data value is sent. This allows the engineer to view the information as it arrives at the device under test and use other channels of the oscilloscope to probe additional signals showing the response of the device to the command. In addition to triggering on specific addresses and data values, it is also possible for the 'scope to trigger on a range of values, on the start of a data packet, a restart, a stop or a "No Ack" (which occurs when a device fails to acknowledge a command). These capabilities make troubleshooting much faster.
SPI (Serial Peripheral Interface) is a master/slave protocol with chip select lines to address specific devices and data rates up to 50Mb/s using data packets of 8 to 16 bits. As with I2C, it is possible to outfit an oscilloscope with a package which can capture and decode SPI or even to be preset for SIOP (Serial I/O Port) or SSPI (Simplified SPI) data. Typically the user connects the clock to one input channel of the 'scope and the data line to another. As with other protocols, it is a good idea to check for stable, clean clock first. Once the clock is tested and verified to be operating properly, the trace showing that signal can be removed from the display of the oscilloscope so the whole screen can be used for viewing and decoding of the data signal.
A decoded packet of SPI data is shown in the top trace. The clock is below it. Note the trigger setup specifies a data value of 6f which occurs at the small red triangle near the middle of the upper trace.
Other channels of the oscilloscope can be set up to verify proper operation when a specific command arrives. The user can set the trigger of the 'scope to look for either binary or hex patterns in the data. The oscilloscope can also be set to look for a data pattern of a certain length, for example eight bits, regardless of the data value. If desired, some 'scopes can capture a long period of time using a long capture memory.
A packet of RS-232 data is captured and decoded into ASCII. The user can also select hex or binary decoding.
The user can then see multiple data packets and the 'scope can build a table which summarizes the salient features of each packet such as the time of arrival of the packet, the data values and the bit rate. If the user wants to quickly move from viewing/measuring one packet to another, this can be done by clicking (with mouse, stylus or finger on a touch screen) on the table.
Testing RS-232 and generic UARTs.
The UART (Universal Asynchronous Receiver/Transmitter) is one of the oldest and most common serial data devices. UARTs run at a variety of data rates and support a wide range of protocols, the most common being RS-232. There can be 5 to 9 data bits, a start bit, an optional parity bit and 1, 1.5 or 2 stop bits. An application-specific package for a digital oscilloscope can be used to test RS-232 or generic UART signals. The user can specify the bit rate, number of data bits, parity and number of stop bits. The oscilloscope can be set to trigger on parity errors or on specific data values. It is also possible to trigger on values below or above a certain number, inside a range or outside a range. As with other protocols, this allows the engineer to test when a specific condition occurs and view both the serial data line (to see the command is received properly) and to use other channels of the 'scope to monitor device operation. Using an oscilloscope with long memory, the user can capture device operation both before and after a command is received or even watch the response to multiple commands over a longer period of time.
Though each protocol sends data at different rates and uses different formats, many of the troubleshooting techniques are similar. The first step is to be able to trigger stably on the event of interest and view it on the screen of the oscilloscope. This can be accomplished by using a 'scope equipped with an application-specific package for the type of serial data being tested. In some cases, it is possible to obtain such a package for an oscilloscope that is already in the test lab. If you view the data signals and they look OK to you but your device is not responding properly, the next step is to verify the signal meets the specific properties mandated by the standard. These are usually set by a committee that writes a long document — part of which specifies the physical layer operation of the protocol. Some of the most common signal characteristics that need checking are the amplitude of the signal, its rise time, fall time and pulse width.
Oscilloscopes have automated parameters which will check many key characteristics of the signal and display the worst case values (maximum and minimum). Some 'scopes will even draw a histogram (bar chart) showing the distribution of the values.
A single packet of data is captured. The amplitude (top voltage minus base) is measured as are the widths of all 50 pulses, the 51 rise times and 51 fall times. The user can see worst case max/min values of all parameters. Millions of packets can be captured and statistics or histograms used to show parameter distributions.
In making these measurements, it's possible to find the parameter for pulse width has an expected range of values but also has a few rarely occurring very short pulse widths (glitches). The next step is to set the 'scope to trigger on very short pulses and probe around to see what is causing them. Some oscilloscopes allow you to test multiple protocols at the same time. You might have SPI on trace 1 of the 'scope and be looking at a UART signal on another trace. This can allow you to see the timing between commands/data in multiple protocols. Another common troubleshooting technique is to look at the latency between when a command arrives at a device and when the device executes its function. If the latency has been measured many times, there may be a prompt response on most occasions but perhaps the device responds very slowly or in rare instances, not at all.
Today's oscilloscopes can test a wide variety of protocols in addition to the ones specifically discussed here. Whether testing CANbus, LIN, or I2S audio signals, many of the same techniques for capture and troubleshooting apply. In more advanced cases such as a device with control signals sent via a slow-speed data bus, such as one of the ones discussed here, the data might be sent via a very high speed protocol like the new super speed USB, SAS, SATA, PCI-Express or other multigigabit per second formats. The good news is that a single oscilloscope can now capture and analyze all speeds of signals and many of the techniques for troubleshooting are common across different protocols.
Contact: LeCroy Corp., 700 Chestnut Ridge Road, Chestnut Ridge, NY 10977-6499
800-553-2769 or 845-425-2000 fax: 845-578-5985 E-mail: email@example.com Web:
© 2015 USTECH. All Rights Reserved. |
Contact Us: 610-783-6100 | firstname.lastname@example.org
powered by GIM