unpredictable ordering of received data

[ehiverson]

Hello,
I've spent a lot of time trying to get this library to work with the slave implementation. The most persistent problem is that the received data doesn't stay in the same order as the master sends it. It is off by a few indexes. Has anyone else had this issue? I'm using a teensy 3.0 as master and a 3.1 as slave.
Also, in the end, I'd like to use this library to configure a teensy 3.1 as slave, and to send data to a master on a TI F28x MCU. The differences are that the TI has continuous clocking, and the enable pin stays low for the entirety over multiple transmit frames. So I made some changes to the master to reflect this behavior so I can test the slave mode with it. Also, in my teensyduino code, I implemented an addressing check since there is another slave on the bus. And in order not to drive the MISO line when another slave is transmitting, I configure the pin as a GPIO input when the address is incorrect. I'm sending just 4 8bit frames, and an ISR is called for each item in the RX FIFO on the slave. When I test with teensy 3.0 master, the ISR is called reliably 4 times. BUT, when I switch to the TI master, the ISR is called an unpredicatable number of times, and all the data gets screwed up, and also the state of the dataPointer and packetCT in this library. Any idea why the behaviour is so different, and why the data is always offset by a few indexes between master and slave? Thanks.

[btmcmahan]

ehiverson, I have experienced this problem you are describing, about the data being off a few indexes. Unfortunately I don't have a good solution.

Here is an example of the problem:
The master sends out 1, 2, 3, 4 in four separate SPI transactions.
wait 20 microsecond...
The slave reads 0, 1, 2, 3.

For some reason, and I can't figure out why, the slave seems to boot with a 0 value already inside the spi register. I can't seem to prevent this, but I have been able to do a Syncing process to get the data aligned. Such at the master sending a sync byte, and the slave has to read the correct byte before moving on. This is of limited help though, it doesn't always work.

I have noticed this: When a transmission is completed, you can wait a little bit (maybe 20 or 50 microseconds) before "POPPING" the data from the slave spi register. This seems to make it run more efficiently. I think this is the amount of time it takes for the data to get clocked into the correct registers inside the chip.

As I have said, I'm not sure why these issues occur, because its using the chips native spi functions. I've tried all kinds of ideas, and spent a lot of time trying to get the master/slave data to align correctly, and still have no good answer. I'm very sorry. But I sincerely hope that someone smarter than me can come up with a solution.

On another note, Paul once made a comment that we might get faster speeds if the data uses one of the DRAM flags to get shifted into the RAM. I don't know how to do this, and I'm not gonna try to learn. But it might help.

[ehiverson]

For me, the problem is slightly worse than being off by 1 index. If I send [0,10,20,30,...150](16 values, sent in 4 packets of 4 bytes each), I read [0,150,0, 10, 20,..] or something like that.

[btmcmahan]

Are you "Popping" the data often enough? There are only 4 registers for incomming data, so for every 4 int of data received, you must pop your received data to make room for the next 4 ints. If not, you are overwritting one of the other numbers.

I have also seen similar data errors if you don't use a small delay after the spi transmission has ended. After the transmission is ended I use a 20 or 50 uSec delay before popping the data. Dont know why this is necessary, but in my application I had similar issues if I didn't have the delay.

[dahollen]

I was receiving corrupted data, particularly in the first byte of the fifo. The manual specifies the SPI module must be halted before clearing the receive fifo. Doing so fixed my problem. Here is an example of before and after:

Before:
SPI0_MCR |= SPI_MCR_CLR_RXF;

After:
SPI0_MCR |= SPI_MCR_HALT; //halt the SPI module
while (SPI0_SR & SPI_SR_TXRXS); //wait for the SPI module to stop
//clear the fifo, keeping the SPI halted
SPI0_MCR |= SPI_MCR_CLR_RXF + SPI_MCR_HALT;
SPI0_MCR &= ~SPI_MCR_HALT; //Start the SPI module running again
while (!(SPI0_SR & SPI_SR_TXRXS)); //verify SPI module running

And thank you, btmcmahan, for posting this library.