I2C SPI USB CAN eSPI Cable Testing View All Quick Start Guides User Manuals Software Downloads Knowledge Base Videos Case Studies App Notes White Papers Sales Support How to Order
Products Blog Sales Support Contact Search
How to Configure SPI Slave Responses for Proper Operation
Published: 2026-01-14
Rena Ayeras

Configuring SPI devices for correct slave response

Image by Geralt

Question from the Customer:

I purchased the Aardvark I2C/SPI Host Adapter and am testing it with an external SPI master device. I preloaded a 10-byte slave response message to the Aardvark adapter (configured as the SPI slave).

The Aardvark slave appears to have received the MOSI data correctly, but the data returned on MISO appears to mirror the MOSI data instead of the expected pre-loaded slave response. The transaction log shows the expected values on MISO, but the reading on pin 5 from the connector shows the values that were received on MOSI at pin 8.

What configuration issue could cause this behavior and how can I resolve it?

Note - the CWs are 16 bits. Here are results shown from Control Center Serial Software:

Control Center Software display of SPI Control transactions

Response from Technical Support:

Thank you for your question! Your assessments of the roles on the Aardvark adapter pins while in SPI mode are correct:

  • Pin 8 (MOSI): receives data from the SPI master device, sent to SPI slave device – in this case, the Aardvark adapter
  • Pin 5 (MISO): sends data from the slave device to the master device.

We have tips and techniques for approaching this behavior, which are described below:

Response Message Troubleshooting Tips

If MOSI and pins show identical data during slave operation, the possible causes include:

  • Loopback configuration, where MOSI and MISO are physically connected or shorted.
  • Software configuration errors, such as using the same buffer for transmitting and receiving, or misconfiguring the Aardvark adapter or your test setup.
  • Electrical connection problems, such as floating or joined signal traces.
  • Timing violations, where insufficient setup time results in MISO repeating the received MOSI byte because the Aardvark adapter did not load new response data. For example, a 4us delay is required between master bytes.

Troubleshooting Steps:

  • Ensure Aardvark slave response (MISO) is set correctly and loaded before each master transaction to avoid echoing the MOSI data.
  • Validate connections to avoid shorts or to ensure proper routing between MOSI and MISO.
  • For correct MISO operation, observe the timing requirements: minimum delays between SPI transactions to allow MISO data setup.
  • Review the SPI mode and clock polarity/phase settings on master and Aardvark, as mismatches can cause data confusion.

If issues persist, carefully check physical wiring and capture signals on both pins with an oscilloscope to verify unique data transfer directions.

Configuring a Slave Response Message

Note – the Aardvark Adapter can only send byte-by-byte data – the Aardvark adapter is prone to inter-byte delay. For more information, refer to Aardvark SPI AC Characteristics.

For the behavior you described, the known solution with the Aardvark adapter is preloading the entire MISO response before Chip Select (CS) goes Active. Here are the configuration steps and known limitations:

  • A slave response message can be set in the adapter as a response to a write request. The message entry field operates in the same manner as the I2C master message to send field.

      • The maximum message size for the Aardvark adapter is 64 bytes.
      • The message can be loaded from a binary file by clicking on the "Load" Conversely, the message can also be saved to a binary file by clicking on the "Save"button.
      • If more bytes are requested in a transaction than have been specified in the slave response, the response string will be wrapped as many times as necessary to complete the transaction. For example if the slave response has been set to 00 01 02 03 04 and 12 bytes have been requested,

        the response that is sent to the master will be 00 01 02 03 04 00 01 02 03 04 00 01

    To set the response in the slave, click on the "Set Resp" button.]

Note - we strongly recommend setting up the slave response before enabling the slave. If a response is not set before the slave is enabled, it is possible that a slave response be requested before the slave device has defined data to return.

Alternate Solution for Inter-Byte Delay of Slave Response Messages

In place of the Aardvark adapter, for greater speed and eliminating the inter-byte delay, we recommend the Promira Serial Platform.

Based on the SPI Active Level license, SPI programming speeds on the Promira platform can be over eight times faster than the Aardvark I2C/SPI Host Adapter, and does not have an inter-byte delay, unlike the Aardvark adapter’s 4-µs delay requirement. Here is a summary of functionalities of the Promira platform:

  • The Promira platform, equipped with the SPI Active applications, provides fast programming, ultra-high-performance debugging, and superior emulation for your SPI protocol needs.
  • Integrated level shifting ensures operation across a wide-range of voltages ranging from 0.9 V to 5.0 V, and includes USB 2.0/Ethernet connectivity.
  • The Promira platform can be configured as an SPI master up to 80 MHz or as a slave up to 20 MHz.
  • Depending on the application license, the Promira platform can support additional or enhanced features such as increased I2C/SPI speeds, Quad and Dual I/O SPI, I2C/SPI protocol analysis, and more. As requirements change or grow, Promira Applications can be purchased, downloaded, and installed via the Total Phase website.
  • For more information refer to the Applications section of the Promira Serial Platform System User Manual.

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.