We are using the Aardvark I2C/SPI Host Adapter and Control Center Serial Software in our test environment. We have encountered the following discrepancies during our evaluation tests:
- When sending data from our board to the Aardvark adapter (11 22 33), the values read through the software are incorrect. For example, 11 22 33 is read as 2C 4A 5D: the transmitted value 11 is always displayed as 2C. The data is being received, but not represented correctly on the interface.
- We checked the transmitted data with an oscilloscope, and confirmed that the correct values are leaving the board. This issue does not seem to originate from the hardware output.
- Additionally, when attempting to transmit data from the Aardvark adapter, we observe a similar problem. For example, when sending 11 22 33 44, the output is 11 10 11 12. In this case, only the first byte is correct while the subsequent bytes are incorrect. This behavior was also confirmed on the oscilloscope.
Our questions:
- Are there any specific configuration settings (such as SPI slave or SPI GPIO modes) that we may have overlooked?
- What factors could explain the mismatch between the transmitted/received data and the displayed data, and what steps are recommended to ensure consistency?
Thank you for your questions! The behavior that you describe is a configuration problem with the data frame, which can be easily resolved. To help you determine the correct configuration, information about data frames and clock edges is described below.
Data Misinterpreted with Incorrect Clock Edges
When using the Aardvark adapter in SPI modes, data misinterpretation can occur if the master and slave disagree on the clock edge for data transfer or if the transfer starts with the wrong polarity from the idle state. To correct this error, ensure the SPI master and the slave chipset are operating in the same mode, and that they “agree” on the data frame. All that is related to the four modes of clock phase and clock polarities as shown below:
- 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 to high clock transition) and data is output on a falling edge (high to 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
How data sampling works:
- 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.
Troubleshooting Guidelines
For additional information about SPI data frames and troubleshooting, refer to the following articles:
- Understanding SPI Clock Signals: Polarity, Phase, Clock Edges, and SPI Modes
- What is the SPI Protocol and How to Debug SPI Communication?
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.