AnsweredAssumed Answered

SPI chip select for multi-byte transactions on mx6sl with 3.0.35

Question asked by jayakumar2 on Mar 16, 2016
Latest reply on May 23, 2017 by GregT

Hi,

 

We're working on interfacing with a spi flash chip on a 6sl board. We've

been able to get the general form of the spi transaction looking

correct but we're seeing an unexpected behavior with chip select.

 

I've attached a scope trace from the device. It shows what should be an

8-bit write (read-status instruction 0x05) followed by an 8-bit read.

The chip select should be kept asserted in between the write and read

but we're seeing that the 6sl spi driver seems to deassert it. The

userspace code we're using does:

READSTATUS_rel204.png

        struct spi_ioc_transfer mesg[2] = { 0, };

 

                mesg[0].tx_buf = (unsigned long)out_buffer;

                mesg[0].rx_buf = (unsigned long)NULL;

                mesg[0].len = 1;

                        mesg[0].cs_change = 0;

                num_tr++;

 

                mesg[1].tx_buf = (unsigned long)NULL;

                mesg[1].rx_buf = (unsigned long)in_buffer;

                mesg[1].len = 1;

                        mesg[1].cs_change = 1;

                num_tr++;

 

                ret = ioctl(fd, SPI_IOC_MESSAGE(num_tr), mesg);

 

So it seems like the spi driver is ignoring the cs_change value set to

0 in the transmit message (mesg[0]) which should tell it to keep CS

asserted.

 

Looking on the fsl community threads, I found a thread from 2013 that

describes our problem exactly. It says:

"

My device requires that the CS be held for the entire transaction (cmd

byte + N data bytes returned from the device), however when I observe

the spi transfer on my logic analyzer I noticed that the i.MX6

releases CS between each data word.  My device will not shift out its

data in this case.

"

https://community.freescale.com/thread/309866

 

I tried applying the patch from Jeff Coffman and it didn't apply on my 3.0.35 kernel. I fixed it up, looks like just positioning issues (patch attached) but when I tested it with an 8-bit write+read, it hangs the system.

 

I'm now thinking it may be quicker for us to force SPI_NO_CS and just

disable the mx6's spi controller cs handling and do the CS using gpio

in userspace rather than trying to fix the controller driver.

 

Please let me know what you think. Would appreciate any advice.

 

Thanks!

Original Attachment has been moved to: spi_imx.3.0.35.patch.zip

Outcomes