Setup time for SPI data too short

Technical Support
, , , ,
1

I have run a simple test to check the configuration of my SPI (as close to default as possible), and I’m worried by what I see on the signals, in particular SPI_CLK does not look healthy:

1698-scope-0.png
1698-scope-0.png800×503 12 KB

This shows a two byte transaction sending the string {0xFF, 0xAA}.
The top signal (green) is connected to SPI CS (pin 86), the middle signal (yellow) to SPI CLK (pin 88), and the bottom (blue) to SPI TXD (pin 92). I am troubled by the following two details, both affecting the clock:

  1. The falling edge of CS and rising edge of CLK are almost synchronous, and it looks as if the hold time for the first data bit is truncated to half a clock cycle.
  2. There is a 60ns clock glitch between the first and second bytes. This is likely to cause my target hardware trouble. (Ok, not a “glitch” as such, but definitely a drastically truncated clock pulse.)

I’m hoping that I’ve simply misconfigured my SPI device, or perhaps am not talking to /dev/spidev1.0 correctly. My device tree is based on vf500-colibri-eval-v3.dts, with my customisations replacing vf-colibri-eval-v3.dtsi:

&dspi1 {
    status = "okay";

    spidev1: spidev@0 {
        compatible = "toradex,evalspi";
        reg = <0>;
        spi-max-frequency = <10000000>;     /* 10 MHz */
        status = "okay";
    };
};

and my test code is the following:

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/spi/spidev.h>

int main(int argc, char *argv[])
{
    char data[] = { 0x55, 0xAA };
    struct spi_ioc_transfer command = {
        .tx_buf = (intptr_t) data,
        .len = 2,
    };

    int dev = open("/dev/spidev1.0", O_RDWR);
    ioctl(dev, SPI_IOC_MESSAGE(1), &command);
    close(dev);
    return 0;
}

P.S. I’ve realised that my data clock is only running at 400kHz! Is this the highest available speed under 10MHz for this device?

2

Hi

To increase the time between two subsequent 8bit transfer please have a look here.

With regard to the SPI clock. Did you try to actually request a clock frequency in the strucht spi_ioc_transfer. I guess speed=0 will set the lowest possible frequency.
You could also reference the spidev_test code from the kernel.

Max

3

Well, that is interesting. That looks like exactly the same problem.

Setting .speed_hz = 10000000 makes no difference, alas, so I suspect the default of 0 is to select the default frequency, and yes, my code is digested from spidev_test.c.

The variables fsl,spi-cs-sck-delay and fsl,spi-sck-cs-delay look like exactly what I need, thank you (the relevant documentation seems to be spi-fsl-dspi.txt).

I will investigate … but something very odd: I have just powered the system on with the same
configuration as before … and I’m now seeing the correct behaviour (8MHz CLK frequency, sensible setup on the first bit, proper bit separation between the two octets).

4

This is very strange: this system was power-cycled for the first time after quite a lot of reconfiguration experiments with the device tree, and now it is behaving as expected (sensible clock frequency, correct separation of octets, correct setup for first bit).

Perhaps the driver for the DSPI does not correctly fully reinitialise all its resources on reboot, and maybe I had left something in an invalid state with a misconfigured device tree?

5

hi @araneidae, we will wait for the results of your investigation.

6

Unfortunately I’ve nothing more to add: the problem went away on a power-cycle and hasn’t recurred! I now (appear to) have a working system.

If the issue does come back I’ll do my best to reproduce it and return to this question, but for now I think my problem is solved (and the -delay parameters will help me tune any issues with my slaves if necessary).

7

Perfect that your issue is solved. Thanks for the feedback.