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, ¶m);param = SPI_CLK_POL_PHA_MODE0;ioctl(g_SPI_DEV_fd, IO_IOCTL_SPI_SET_MODE, ¶m);param = SPI_DEVICE_MASTER_MODE;ioctl(g_SPI_DEV_fd, IO_IOCTL_SPI_SET_TRANSFER_MODE, ¶m);
param = HW_SPI_CS_FPGA;ioctl(g_SPI_DEV_fd, IO_IOCTL_SPI_SET_CS, ¶m)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);
Well, I knew that just after asking here I'll find the answer. If helps, I've just found this:
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
So I think this is what I'm getting. :smileysad: