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
How Do I Troubleshoot an SPI Slave Device that Sends Erroneous Data?
Rena Ayeras

When there's a problem, apply analysis and determine the solution

Image by Geralt

Question from the Customer:

I am working with the Promira Serial Platform as an SPI master in mode 0. Should the MISO signal be sampled on the falling edge of the clock signal, or at the rising edge? Looking at the results with Control Center Serial Software, I see a mismatch between the input and output signals.

The setup:

  • The Promira platform is the master device, working at 4MHz.
    • The measured hold time is about 70 ns, which should be acceptable, as the Promira platform datasheet specifies minimum hold time as 3 ns.
  • A chipset is the slave device.

What I see:

  • The Promira platform transmits (MOSI): AABBCCDD – using an oscilloscope, I see the slave does receive this payload.
  • The slave transmits (MISO): 12345678 (the slave did receive the correct payload from master).
  • The GUI displays 2468ACF0.The Control Center shows the output data that the user knows is incorrect.

What could make the slave device constantly send erroneous data?  The information received is correct, and the functionalities of the chipset have been tested and verified.

Response from Technical Support:

Thanks for your questions! To help you understand the process, we will go over how data is mapped. Then we will proceed to troubleshooting techniques and test setups that could work for you.

How Data Signals are Read

Here is an illustration that maps CPOL and CPHA to mode numbers.

Timing diagram of SPI signals: CPOL and CPHAImage source: Serial Peripheral Interface

The following phrase describes the method by which each mode of SPI (0,1,2,3) can be mapped by checking how the data is sampled by referring to the above diagram simultaneously.

  • At CPOL=0 the base value of the clock is zero, i.e. the idle state is 0 and active state is 1.
    • For CPHA=0, data is captured on the clock's rising edge (low→high clock transition) and data is output on a falling edge (high→low clock transition).
    • For CPHA=1, data is captured on the clock's falling edge and data is output on a rising edge.
  • At CPOL=1 the base value of the clock is one (inversion of CPOL=0), i.e. the idle state is 1 and active state is 0.
  • For CPHA=0, data is captured on clock's falling edge and data is output on a rising edge.
  • For CPHA=1, data is captured on clock's rising edge and data is output on a falling edge.

Data Sampling

  • When CPHA=0, sampling occurs on the first clock edge; data is transmitted on the active to idle state. NOTE: with CPHA=0, the data must be stable for a half cycle before the first clock cycle.
  • When CPHA=1, sampling on the second clock edge, regardless of whether that clock edge is rising or falling; data is transmitted on the idle to active state.

If transmission happens on a particular edge, then capturing occurs on the opposite edge. For example, when transmission occurs on the falling edge, then reception occurs on the rising edge, and vice versa.

MOSI and MISO signals are usually stable (at their reception points) for the half cycle until the next clock transition. SPI master and slave devices will sample data at different points during that half cycle.

Observed Issue and Resolution

Data being shifted by one bit is the common symptom in SPI when the wrong clock setup is used. Either the master and slave disagree on what clock edge data is transferred, or it is starting at the wrong polarity from idle.

Ensure the Promira SPI master and the slave chipset are operating at the same mode. The master and slave must agree about the data frame for the exchange.

Troubleshooting Data Delivery

Troubleshooting is a large subject. The issue could be the setup or the chipset itself. Here are our recommendations for analyzing your project:


Use the High-Speed SPI Flash Demo Board, an effective tool for debugging a system against working slave devices, to create a prototype of the system. This can help differentiate hardware and software bugs. The board is also useful to establish a baseline for software usage. For an example, go to the Knowledge Base article Programming an SPI Flash Using the Promira Serial Platform and the Control Center Serial Software. The article describes the steps for Programming SPI Flash M25P32 found on the board. Similar steps can be used for other devices.


Knowing the details of the actions are key to resolving an issue. The best way to achieve this is using Beagle I2C/SPI Protocol Analyzer.  Place it in the setup and log the required information using Data Center Software. This enables you to monitor the flow of data on the bus, facilitating real-time monitoring along with diagnostics and communication. For example, take a look at the video and see how it can be used to quickly evaluate a system.

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.