Weird SPI behavior on iMx6 running 3.14 Linux kernel

[cavebiker]

I have an iMx6 Quad board running SPI channel-2 using pins (CSI0_DAT10) for MISO, pin (EIM_CS1) for MOSI and pin (EIM_D24) for the Chip select.

I am seeing weird behavior with just this chip select where a valid 32-bit SPI transmit takes place to a slave SPI device. Than after some time running SPI OK the iMx6 locks the Ship Select signal active (low) forever. Killing the process of course, and killing all the fun.

Has anyone else seen any issues like this and/or has a fix?

Thanks a ton in advance.

Cheers,

Tom

[cavebiker]

Here is an image of what a normal SPI packet looks like: The iMx6 is the SPI master. Yellow is SPI Clock, Blue is MOSI, Green is MISO, Pink is SPI Chip Select

Below is the image of when the iMx6 Linux SPI driver dies: I'm triggering on the Ship Select going low(active).

When the SPI driver dies, the Chip Select stays active low forever. And all other SPI activity with that clock halts.

There are three slave devices sharing this clock. Only when a slave SPI device is plugged into the Chip select pin (EIM_D24) and another is plugged into the Chip Select pin (DISP0_DAT15) does this SPI driver crash issue occur.

I'm a Kinetis guy and in Kinetis, SPI is handled through hardware, and this condition could never happen.

What I am being told is that on the iMx6, SPI is derived through software. So for some reason the SPI software in Linux is crashing, as seen by the Chip Select signal hanging low forever.

Also, this problem is intermittent. I cannot get this to happen on older revision iMx6 boards. And the newer revision boards will only die on 20% of the boards. Because of this I want to blame the iMx6 silicon, because if it were software it should happen on all boards, even the old boards because they all run the same software.

We are going nuts here so any help or suggestions will be much appreciated.

Cheers,

Tom

[cavebiker · Accepted solution]

All right, we seem to have a workaround!

The Problem:

For some reason the Linux low level SPI driver acquired spurious data in a RX-fifo buffer, and only on some boards and only after an extended run time. The result is the SPI driver does not know what to do with this extra RX-fifo data that it did not ask for with its SPI clock, so it hangs. In my opinion this is a bug in the Linux SPI driver because this data is in the RX-fifo buffer before the driver asserts the SPI chip select requesting data, so this data was not asked for and should .  

The Solution:

In the low level SPI driver, just before the driver asserts the SPI chip select we are now clearing the entire RX-buffer. next we assert the chip select, fire off the 32-SPI clocks and read the incoming 32-SPI bits. All good! We ran for over three days on 3-boards and had no issues. Yahoo!

Cheers,

Tom

[fabio_estevam]

Hi Tom,

Could you please share your changes in a patch format?

Thanks