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?
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:
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.
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.
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.
Test with Different SPI Modes: Experiment with different SPI modes (e.g., CPOL and CPHA settings) to see if they affect the CS timing.
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.
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:
