ECSPI Chip Select Idle time

Hi there,

Here’s my Hardware and Software setup
Hardware info

HW model: Toradex Verdin iMX8M Plus on Verdin Development Board
Toradex version: 0061 V1.0B
Serial number: 06849350
Processor arch: aarch64

Software summary

Bootloader: U-Boot
Kernel version: 6.6.54-gdbf52fc7ac3a-dirty #20 SMP PREEMPT Thu Feb 27 20:03:59 IST 2025
Kernel command line: root=PARTUUID=55c53785-02 ro rootwait console=tty1 console=ttymxc2,115200
Distro name: NAME=“TDX Wayland with XWayland”
Distro version: VERSION_ID=7.1.0-devel-20250116090100-build.0
Distro variant: -
Hostname: verdin-imx8mp-06849350

Issue:

I am facing an issue where the Chip Select (CS) remains high for approximately ~4-5 µs after SPI transfer api calls.

Initially, while using DMA, I observed SCLK assertion delay after CS getting low, It is around 2.2 µs after CS starts. I received a suggestion to use native CS with DMA disabled.

Now, I have disabled DMA and am using native CS for the SPI peripheral, but I still observe that remains idle for approximately ~4-5 µs.

Even when I increase the SPI clock speed, the idle time of CS remains almost same, while the low time (transaction time) improves.

Can you please tell what’s causing this issue? And any steps to resolve it?

Any help / suggestions would be appreciated

Case-1: Using HW Chip Select
Please refer attached image to analyse below signals

Top Line : GPIO used to monitor SPI transfer API called.
Middle Line : Chip Select
Bottom Line: SCLK
SCLK Frequnecy : 35Mhz

Because of this delay getting added to every transaction we are facing low throughput issue on SPI slave device. We have observed this even when we do not connect any SPI slave device same issue is happening.
Thanks,
Pratham

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello Pratham,

Thank you for reaching out with your question. The issue you’re experiencing with the Chip Select (CS) line remaining high for 4-5 microseconds after SPI transfer API calls can be due to several factors, primarily related to software configuration or inherent hardware characteristics.

Here are some steps you can take to troubleshoot and potentially resolve this issue:

  1. Check SPI Configuration: Ensure that the SPI bus and device are correctly configured in the device tree. Verify that the SPI clock speed and mode settings are appropriate for your application.

  2. Review SPI Driver Settings: Since you are using native CS, check the SPI driver settings in the kernel. Look for any parameters related to CS timing or delays that might be configurable.

  3. Examine Kernel and Driver Code: If you have access to the kernel source, examine the SPI driver code for any hardcoded delays or timing constraints related to CS handling. Modifying these might help reduce the idle time.

  4. Test with Different SPI Modes: Experiment with different SPI modes (e.g., CPOL and CPHA settings) to see if they affect the CS timing.

  5. Consider Hardware Characteristics: Some delay might be inherent due to the hardware design or the way the SPI controller handles CS. Reviewing the hardware documentation for any known limitations or timing specifications can be helpful.

  6. Use Logic Analyzer: If you haven’t already, use a logic analyzer to capture the SPI signals and verify the timing of CS, SCLK, and data lines. This can provide insights into where the delay might be occurring.

By following these steps, you may be able to identify and mitigate the cause of the CS idle time. I hope this helps you improve the throughput of your SPI slave device.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Disable SPI-DMA on NVIDIA to support spi-read.

Here’s the snap for Case 2 when using the Software CS Pin (cs-gpio) .

Here too we are seeing the CS being idle for some time before SCLK starts.