Article by: Teledyne LeCroy
Another aspect of IoT debugging and validation is the low-speed serial data standards used to facilitate communication between ICs and between controllers and peripherals.
The last article discussed the difficulties in receiving the many sensor signals that can be fed into a deeply embedded system, such as an IoT device, as well as a hardware solution: to the problem. Another aspect of IoT debugging and validation is the low-speed serial data standards used to facilitate communication between ICs and between controllers and peripherals (Figure 1). So let’s take a look at three such low-speed standards: I2C, SPI, and UART.
Here are brief summaries of these three serial data standards:
- I2C: The Inter-Integrated Circuit protocol is for short-range communication between peripheral ICs and processors.
- SPI: This standard, also called Serial Peripheral Interface, is used for short-range communication in embedded systems.
- UART: The Universal Asynchronous Receiver Transmitter protocol applies to the serial port communication of the device.
Figure 1: Serial data links handle traffic between ICs and peripherals in the IoT world.
Our generic IoT device block diagram of Figure 1 implies that a given device could use all three of these serial data standards. In figure 2 we see a screen shot of all three signals taking place simultaneously. The table at the bottom left shows the message times between messages. If there was a case where there were a few UART messages with SPI and I2C messages in between, they were all stitched together in time in the table. The SPI messages are highlighted in blue on the display. The top left grids show the original acquisitions, while the top right grids show zoom traces of three messages.
Figure 2: Shown are all three serial data standards captured simultaneously.
In Teledyne LeCroy’s setup dialog for decoding serial data streams, the variables are plain and simple. For example, in the UART configuration, it is easy to set a certain bit rate, number of bits, bit order, polarity and other parameters.
What can one obtain from a serial bitstream? Basically, all that matters, as seen in Figure 3. In this example, the oscilloscope was set to trigger at I2C address 30. In the acquisition track at the top, notice that the ID 30 is highlighted in red just to the left of the trigger point. The decoding table on the left shows the I2C message highlighted in yellow in the middle of a series of SPI messages. The ability to correlate these different bus events over time helps determine cause-and-effect relationships between activities in different serial data protocols.
Figure 3: The dialog box at the bottom makes it easy to set up protocols.
Figure 4 shows a snapshot of bus-specific parameter measurements. At the top left, serially encoded data can be viewed as an analog waveform. In this way, transmitted digital data can be brought into the analog world and viewed as a waveform. An extremely useful tool is Message to Analog, which allows you to measure the timing between serial data bursts and a control signal. With the reverse, analog to message, you can measure the timing between when the control signal goes off and when the serial data burst occurs. The Message to message tool can determine the timing between, for example, messages on the SPI and UART buses.
Figure 4: This snapshot shows a number of tools useful for serial data debugging.
The bus load percentage tool is valuable for inferring how much a particular bus is or is not being used by the system. For example, let’s say you want to see how many times ID 46 appears on the I2C bus. It could be a sensor signal of interest, or it could be a particular message you are looking for. The tool allows you to isolate that ID and perhaps discover that it is less than 1% of the bus traffic. Do you want to know how active the I2C bus is in general? Simple; just don’t filter by a particular ID.
Equally valuable are the statistical capabilities of the oscilloscope. The green-lined area at the bottom left of Figure 5 shows us the statistical data on the different parameter measurements being performed, and below each column of statistics is a histogram showing the distribution of the measurement. The screenshot shows that more than 28,000 messages bit rate measurements have been made. The histogram shows peaks in the distribution at the high and low ends, an almost sinusoidal shape. This could indicate a problem that should be investigated.
Figure 5: Statistical data reveals a lot about bus activity.
Meanwhile, at the top right are another histogram, trend plot, and track plot. Together, these form a graphical representation of data about these bus measurements from our IoT device.
While we’re doing our research on the serial buses, we might also want to see what’s going on with the DC busbars. Figure 6 adds those gains in the green outlined area. We can see small notches appear in the orange waveform that should be a flat DC level. On the right is a frequency domain of the same signal, where we can examine the frequency content of those notched regions.
Figure 6: An FFT of the DC busbar helps to unravel DC power level problems.
