VF61 SPI clock timing between bytes

Yes, it does!

But I believe that is necessary to change the documentation here to indicate that changing the delays fsl,spi-cs-sck-delay and fsl,spi-sck-cs-delay will change the timing between words in a transfer as well. And this will be them sum of the delays.

Hi @stefan.tx,

The blue one is the clock, and the yellow one is the Chip Select.

The mode I’m using is SPI_MODE_0 (CPOL=0, CPHA=0). So the sampling is in the clock rise edge.

What I was trying to do was to insert a 100ns delay from the chip select falling edge to the start of the clock pulses. Without the delay, the rise edge of the clock starts after 20ns. And the IC I’m using request at lest 35ns before the clock rise edge. As I simply copy the variables fsl,spi-cs-sck-delay and fsl,spi-sck-cs-delay from the documentation, I use the values:

fsl,spi-cs-sck-delay = 100 and fsl,spi-sck-cs-delay = 50;

After insert the delays, the result was a delay of 120ns from the chip select falling edge to the clock rise edge, and 80ns from the end of clock to the rise edge of the chip select. But the sum of the delays 100ns + 50ns appears between the words in the transfer as well; The total value was 40ns seconds of the original delay from the words (when the clock is set to 10MHz) plus the 150ns seconds of the delays, witch is 190ns (mark of the measure traces showed in the captured image from the oscilloscope).

The problem is that the word “transfer” is used in two different domains here: In the Linux software abstraction, a SPI transfer is one unit sent to the driver. It is part of the drivers work to split such a transfer down to whatever the hardware supports (depending on FIFO/DMA etc…)

The DSPI uses the word transfers in the sense of bursts from its FIFO to the transfer engine, which is typically 8-bit. That is the reason you see the delays also between bytes…

Optional SPI slave node properties:
- fsl,spi-cs-sck-delay: a delay in nanoseconds between activating chip
  select and the start of clock signal, at the start of a transfer.
- fsl,spi-sck-cs-delay: a delay in nanoseconds between stopping the clock
  signal and deactivating chip select, at the end of a transfer.

That said, I agree, especially for the Linux kernel binding description using the word transfer is misleading, especially since it also mentions at the end/beginning of chip select. Normally, the IP would return the chip select to high after each (IP) level transfer (8-Bit), but the driver also uses the continuous mode (see SPIx_PUSHR, CONT).

There is also the FCPCS, which allows to mask these delays (“This bit enables the masking of “After SCK (t ASC )” and “PCS to SCK (t CSC )” delays when operating in Continuous PCS mode.”, see also Fast Continuous Selection Format in the Vybrid RM). It seems that would allow to remove the delays leaving just a gap “half of the baudrate”, which, I guess, would lead to a smooth continuous clock signal… It seems not entirely trivial to do that masking.

I have just seen exactly this same problem, except something very strange: the problem went away as soon as I power-cycled my board.

Hmmm. Rather troubling, to be honest…

Yes, this is strange. Please let us know if you get more information on your issue.
Best regards,