SPI delay between chip select low and SPI clock


We are currently using VF61 with Linux image BSP2.8.6, but we are probably going to switch to IMX6ULL with an appropriate Torizon or BSP image in the near future.
We have configured SPI as a master with a clock frequency of 10MHz but we have some issues reading from the slave, a Sam 53N20 microcontroller.

The main issue is that the VF61 drives the chip select low and then starts to drive the SCLK after just 25-30 ns. However, our peripheral requires at least a 500ns delay.
Is there an option to add a delay between chip select low and SPI clock (on VF61 or IMX6ULL)?
Second issue: is there a way to set a delay between reads of consecutive bytes when we set the SPI to read multiple bytes?


It is controllable via device tree, see VF DSPI dt-bindings.

1 Like

Hi @mnicolas

Please have a look at the link Edward sent.

Thanks @Edward.

Best Regards

Thanks for you answer, we haven’t yet answer of the second issue : is there a way to set a delay between reads of consecutive bytes when we set the SPI to read multiple bytes?"

There’s no option to insert known delay between master SPI bytes, neither on VF nor iMX6ULL.
If your MCU is so slow, then you should further lower SPI clock and fill slaves TX buffer in advance, before CS is asserted, as well while previous byte is clocked in/out, before master starts clocking next byte.

On VF61 you have Cortex-M4 , on which you may implement (almost) any real time protocol, with as big delays between SPI bytes and CS edges as you wish. RPMSG then could be used to communicate that SPI data to/from Linux.

thanks for you answer, now we use the iMx6ull module with(BSP 2.8b7) , the delay between bytes transfer is ok, but we notice that the delay between activating chip select and the start of clock signal is about 35 usec and the delay between stopping the clock signal and deactivating chip select is 180 us ,we tried to change these values by inserting new values into imx6ull-colibri-eval-v3.dtsi device tree file as shown below but nothing is changed, could you indicate what are we doing wrong?.
&ecspi1 {
status = “okay”;
mcp251x0: mcp251x@0 {
compatible = “microchip,mcp2515”;
pinctrl-names = “default”;
pinctrl-0 = <&pinctrl_can_int>;
reg = <0>;
clocks = <&clk16m>;
interrupt-parent = <&gpio2>;
interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
spi-max-frequency = <10000000>;
status = “disabled”;
spidev0: spidev@0 {
compatible = “toradex,evalspi”;
reg = <0>;
spi-max-frequency = <16000000>;
fsl,spi-cs-sck-delay = <10>;
fsl,spi-sck-cs-delay = <10>;
status = “okay”;

this is the link of the file that we used: imx6ull-colibri-eval-v3.dtsi - Google Drive
thanks again


Your initial question had this

We are currently using VF61

and my answer was about DSPI module of VF61.

iMX6ULL uses eCSPI instead, which driver doesn’t have settings for delay between CS and clock. See eCSPI DT bindings
Long CS-SCK delay must be caused by GPIO CS usage. eCSPI module features HW CS, but current driver is limited/broken so that with DMA enabled CS may toggle in the middle of transfer…

really thanks for the support. After we did some further tests by transferring several 512-byte packets using iMX6ULL, we noticed a strange behavior: the delay between stopping the clock signal and deactivating chip select isn’t fixed as shown in these images, could you explain what is it due to?

Yellow: SPI CLK sodimm 88
Cyan: SPI RXD sodimm 90
Green: SPI CS sodimm 86


Dear support, let me better explain our needs: we use the SPI on i.mx6ULL to perform data transfer from a proprietary acquisition board to i.mx6ull.
Our data transfer needs is around 4 to 6 Mbit /seconds, so we need to be as fastest as possible.
We are running at 10MHz spi clock speed, but there is a lot of loose time between CS low to first clock cycle and between the last one clock and the CS high.
In particularly the time between last one clock cycle and CS returning high seems vary from one data transfert to another, As you can see in the previously attached scope image a complete data transfer change from 840usec to 2110 usec.
Is there a way to reduce as low as possible this time loosing?
Thanks in advance


The answer is almost the same. On iMX6ULL you are using GPIO CS, which is software toggled CS… Linux isn’t real time OS and this is why delay is random and often quite long. 2ms delay isn’t worst case delay…
Due to eCSPI driver limitations/oddness you can use HW CS at your own risk only.

Even in VF61 case, which HW CS is okay, you still will have those random delays, not between CS and SCK, but between two adjacent transfers.

Having real time requirements, IMO it is the best to use secondary Cortex-M CPU for real time tasks. Cortex-M isn’t available on iMX6ULL. VF61 is includes Cortex-M4, other iMX’s include it as well, but not iMX6ULL.

Hi, unfortunately i just have a cortex M4 on my acquisition board, so i need to transfer data to i.mx6ull as fastest as possible.

Is there a way to avoid this random delay? Maybe skipping the use of HW CS and managing it by other way, like external hardware… Or random delay will be always present even if i skip the HW CS?

Again, Linux isn’t real time OS, such long jitter jis unavoidable. PREEMPT_RT patch may help, but it’s not panacea and has its own drawbacks.

1 Like