SPI: Possible BUG in SPI chip selects

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SPI: Possible BUG in SPI chip selects

555 Views
Ardoster
Contributor III

Hi

 

I'm not quite sure, but I'm having a problem with SPI's chip selects and for now, my only explanation is about a bug in MQX when using the chip selects. My software must to control 3 different SPI devices, so I use 3 different chip select lines. The problem is that there's a moment all the three chip selects are asserted. This very particular moment is after writing on the bus using:

 

ioctl(fd, IO_IOCTL_SPI_READ_WRITE, &rw)

 

I've attached a screenshot in which you can see this effect:

1) the green line is the chip select line i'm currently using

2) the yellow line is another device's chip select.

3) The purple line is the SCLK line

 

In this screenshot, I'm writing 128 bytes using the previous command. As you can see, after writing 16 bytes, there's a moment the two chip selects are asserted. I'm guessing this unlucky "effect" is causing me problems in one of my SPI devices (a FPGA while downloading the bitstream).

 

What can I do? Any suggestion? Must I do something special to initialize chip select lines???

 

If helps, this is more or less my code:

 

to init device:

 

g_SPI_DEV_fd = fopen(HW_SPI_PORT, NULL);param = HW_SPI_BAUDRATE;ioctl(g_SPI_DEV_fd, IO_IOCTL_SPI_SET_BAUD, &param);param = SPI_CLK_POL_PHA_MODE0;ioctl(g_SPI_DEV_fd, IO_IOCTL_SPI_SET_MODE, &param);param = SPI_DEVICE_MASTER_MODE;ioctl(g_SPI_DEV_fd, IO_IOCTL_SPI_SET_TRANSFER_MODE, &param);

 To write:

param = HW_SPI_CS_FPGA;ioctl(g_SPI_DEV_fd, IO_IOCTL_SPI_SET_CS, &param)rw.WRITE_BUFFER = (char_ptr)buffer;rw.READ_BUFFER = (char_ptr)buffer_rx;rw.BUFFER_LENGTH = (u32)len;ioctl(fd, IO_IOCTL_SPI_READ_WRITE, &rw);fflush(g_SPI_DEV_fd);

 Thanks again

 

 

0 Kudos
1 Reply

181 Views
Ardoster
Contributor III

Well, I knew that just after asking here I'll find the answer. If helps, I've just found this:

 

IO_IOCTL_SPI_KEEP_QSPI_CS_ACTIVE

 

If TRUE, transfers longer than 16 frames are
possible with CS asserted until flush() is
called - with a side effect of holding all chip
selects low between transfers (HW
limitation).

 

So I think this is what I'm getting. :smileysad:

 

Thanks

 

0 Kudos