Imx6 SPI: Long delay between chip select low and SPI clock

Technical Support
, , ,
1

Hello , we need to create a proof of concept (POC) where the IMX6 (Toradex Colibri) communicates with a FPGA via the SPI interface.

We chose to perform this POC on the WEC 2013 platform because we already have a driver that communicates with the FPGA via the EIM bus. At the end, it will therefore be sufficient to replace the EIM bus with an SPI connection.

But now , we just verify that we are able to communicates with fpga via SPI. For this we used the Spi demo and driver downloaded on your website. It’s working but there is a long delay when the SS signal goes low, before data transfer begins.

tek00001
tek00001800×480 97.4 KB

Here we just send 4 bytes at 22MHz, the delay before sending data is 9µs , and 15 µs after
Spi initialisation :

fSuccess = Spi_SetConfigInt(hSPI, L"SpiMode", 1, StoreVolatile);
fSuccess &= Spi_SetConfigInt(hSPI, L"BitRateHz", 22 * 1000 * 1000, StoreVolatile);
fSuccess &= Spi_SetConfigInt(hSPI, L"ioClk", IOCOLIBRIPIN(153), StoreVolatile);
fSuccess &= Spi_SetConfigInt(hSPI, L"ioMOSI", IOCOLIBRIPIN(155), StoreVolatile);
fSuccess &= Spi_SetConfigInt(hSPI, L"ioMISO", IOCOLIBRIPIN(157), StoreVolatile);
fSuccess &= Spi_SetConfigInt(hSPI, L"ioCS", IOCOLIBRIPIN(159), StoreVolatile);
fSuccess &= Spi_SetConfigInt(hSPI, L"BitsPerWord", 16, StoreVolatile);

This delay is really problematic and we want to reduce it significantly. Any solutions ?
Thanks & Regards

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I understand you’re experiencing delays in SPI communication with your FPGA on the Colibri iMX6 running WEC 2013. Let me help you identify potential solutions to reduce these timing delays.

SPI Performance Considerations

Based on the Toradex documentation, the i.MX6 SPI controllers (ECSPI) operate at up to 23 Mbps and provide several features that can impact timing performance (1)(2):

  • 32-bit x 64 deep FIFO (RX and TX) (1)(2)
  • Master/Slave configurable (1)(2)
  • Simultaneous receive and transmit (1)(2)
  • DMA support (1)(2)

Potential Solutions for Reducing SPI Delays

1. Use DMA-Based SPI Library

For better performance with larger data transfers, consider using the SPI via DMA Library (SPIDMALib) (3). This library is specifically designed to manage SPI interfaces via DMA and can provide better timing characteristics (3).

The SPIDMALib supports up to 5 SPI ports on Colibri modules and includes both DMA-based and polling mode functions (3). For data packets smaller than the FIFO (32 frames), the polling mode functions are recommended as they require less overhead and provide shorter latencies (3).

2. Check Your Pin Configuration

Your current pin configuration uses:

  • Clock: Pin 153
  • MOSI: Pin 155
  • MISO: Pin 157
  • CS: Pin 159

According to the Colibri iMX6 datasheet, these correspond to the standard Colibri SPI interface (1)(2):

  • Pin 88 (SSPSCLK): Serial Clock (1)(2)
  • Pin 92 (SSPTXD): Master Output, Slave Input (1)(2)
  • Pin 90 (SSPRXD): Master Input, Slave Output (1)(2)
  • Pin 86 (SSPFRM): Slave Select (1)(2)

3. Optimize SPI Mode and Timing

The i.MX6 supports four different SPI modes (1)(2):

  • Mode 0: Clock positive polarity, data latched on positive edge
  • Mode 1: Clock positive polarity, data latched on negative edge
  • Mode 2: Clock negative polarity, data latched on positive edge
  • Mode 3: Clock negative polarity, data latched on negative edge

Ensure your FPGA and the SPI controller are configured for the same mode to minimize setup and hold time issues.

4. Consider Library Version

The SPIDMALib documentation indicates that Library revision V5.0 and higher automatically handles frequency management between SpiInit and SpiDeinit, which can improve performance (3).

Recommendations

  1. Upgrade to SPIDMALib: Consider migrating to the DMA-based SPI library for better performance characteristics
  2. Use Polling Mode: For small transfers like your 4-byte example, polling mode functions may provide better latency than DMA
  3. Verify Pin Assignments: Ensure your pin configuration matches the standard Colibri SPI interface
  4. Check Library Version: Use the latest available version of the SPI libraries

The 9µs delay you’re observing before data transmission could be related to the library’s internal setup overhead or timing characteristics of the specific SPI implementation you’re using.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hello @slou26 !

Thank you for reaching out!

Before we proceed, we wanted to make you aware that Windows Embedded Compact (WEC 2013) is approaching end-of-life due to CRA (Cyber Resilience Act) compliance limitations. We strongly recommend evaluating a migration to a supported platform. You can find our migration guide here: :backhand_index_pointing_right: WinEC Affected Modules EOL - Migration Guide | Toradex Developer Center

Given that your POC is still in early stages, this might be a good opportunity to consider this transition before further investment in the WEC stack.

That said, someone from our WEC support team will be in touch shortly to assist you with your SPI question.

4

thanks @joaom.tx ,

Yes, we are migrating to Linux, but in the meantime, we need to perform a proof of concept (POC) to determine if the SPI connection is sufficient.
We await a response from your WEC support team.
Thank you.

5

Looks like it is GPIO CS, and 8us isn’t bad for SW toggled GPIO. imx6 should support HW CS capable pads, but perhaps WinCE driver doesn’t support it. If slow CS is the only problem, then sending more data with one CS pulse should help achieving better performance.

6

Hi @slou26 ,

I checked the SPI driver source code and the SPI CS is toggled as a GPIO. This was a modification we did in 2017. Before the driver was using the HW CS driving from the SPI controller. Unfortunately the person that wrote the code at the time is not with Toradex anymore, but if i remember correctly the reason why the CS behaviour was changed to GPIO is because the SPI controller was misbehaving and this was the only workaround.

I think the best thing for you would be to check with the Linux team to see if their implementation meets your expectations as it might behave quite differently.