I2C SPI USB CAN eSPI Cable Testing View All Videos Quick Start Guides Software Downloads App Notes White Papers User Manuals Knowledge Base Sales Support About Us
Products Blog Sales Support Contact Account Search
For Troubleshooting Data Transfers, How Much Signal Detail Can I Read from a Digital Protocol Analyzer?
Rena Ayeras

Artwork by Geralt

Question from the Customer:

I am using the Beagle I2C/SPI Protocol Analyzer and Data Center Software with an product in development. The data transfers go well until the last byte. My assumption is the SPI slave signal line is going high too soon, giving a false indication the transfer is complete. I can see the data streams with the Data Center Software – how can I deeply analyze this issue with the data I see? Here are examples of the information I am looking at:

Details of captured SPI signals Captured Transactions


SPI signal waveforms captured by Beagle I2C/SPI Protocol Analyzer, shown by Data Center Software Waveform View of Captured Data

There may also be a wiring problem. I don’t see how to use the protocol analyzer for that. When talking to the EEPROM chip with a three-byte command address, there are no errors. However, when using a two-byte address as the data specifies, errors occur. In addition to also using an oscilloscope, do you have any suggestions for looking into this problem?

Response from Technical Support:

Thanks for your questions! Protocol analyzers and oscilloscopes are two of the debugging tools used most often. There are times you may need a closer look at the analog aspects of signals. To help you maximize using the Beagle I2C/SPI analyzer, we will go over the details of what the Beagle I2C/SPI analyzer can derive from packets, as well as some troubleshooting tips. We will start with comparing an oscilloscope to a protocol analyzer, and then go into the details of what the Beagle I2C/SPI Protocol Analyzer can do for you.

Oscilloscopes Analyze Low-Level Signals and Bit Streams

Oscilloscopes are useful in debugging systems, particularly for electrical issues, but the data is captured at a very low level. The visual data generated by oscilloscopes can reveal crucial parameters such as jitter, noise, and signal to noise ratio (SNR). In the early stages of development, system designers often use oscilloscopes to look for an event of particular interest, decode an entire burst of serial data, and so on. When using eye diagrams generated by oscilloscopes, the process of debugging can be easier and more efficient. You can quickly find out if there are any signal integrity issues in their prototypes by using oscilloscopes, but they provide little support analyzing high-level data.

Protocol Analyzers Troubleshoot Packets and High-Level Data

Unlike oscilloscopes, protocol analyzers such as the Beagle I2C/SPI Protocol Analyzer allow designers and developers to debug their embedded systems at a higher level. There are two types of protocol analyzers – software and hardware. Although the software analyzer offers an economic advantage, it is limited by the capabilities of the host computer’s hardware. The hardware analyzer has the ability to debug embedded hosts, and it also offers visibility into issues related to timing, transmission, and speed negotiation. Protocol analyzers, including the Beagle I2C/SPI Protocol Analyzer, have their own area of operation and are different from oscilloscopes.

Advantages of Troubleshooting High-Level Data

Protocol analyzers have a significant advantage over oscilloscopes. Protocol analyzers allow developers to view the data in the form of packets, not just individual bit streams. Protocol analyzers also offer a real-time display of the captured data to speed up the process of debugging a system, all of which can be recorded and reviewed with teammates for further analysis. While oscilloscopes are useful in debugging embedded applications, protocol analyzers provide many advantages.

The Waveform view pane, or Timing pane, of the Data Center Software Details window provides bit-level timing for the data of I2C and SPI transactions. Each byte of the transaction appears as a row in this pane. All the bytes from the transaction will be displayed in this , including start and stop conditions. The first line of the table displays the transaction timestamp as well as the transaction duration, both to nanosecond precision.

Each row contains the following information:

  • Offset: The offset position of the byte.
  • Time: The time in nanoseconds from the start of the transaction to the start of the byte.
  • Value: The hexadecimal value of the byte.
  • Timing: A graphic display of each individual bit of a byte.

In the Timing Pane, each bit is displayed as either logical high or logical low. The timing is shown in nanoseconds from the start of the current bit to the start of the subsequent bit. Please note the following limitations of this display:

  • The lengths of the timing blocks in the graph are not drawn to scale. They provide a hint to the relative time scale of one bit time to the next.
  • Depending on the protocol, the bit order may be MSB or LSB. You can determine the bit order by looking at the column label. The text in the label will indicate if the data is MSB (b7...b0) or LSB (b0...b7).

Troubleshooting Tips for Protocols

Signal integrity can be affected by the length of the cable. We strongly recommend using the shortest cables possible in all setups: 5” or less for I2C/SPI cables.

The following that could be useful for your project:

We hope this answers your questions. Additional resources that you may find helpful include the following:

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.