Hello,
while trying to address an external eeprom module from a Teensy 4.0 I noticed some strange behaviour of the SPI library functions transfer/transfer16:
The SPI interface seems to get stuck with a 16 bit frame size after two consecutive calls to transfer16. Following calls to transfer
now clock out 16 bits instead of the expected 8.
I managed to reproduce this behaviour with the following code snipplet:
See the extra 0x00 before sending 0xAA:
Commening out one of the calls to SPI.transfer16 I get the expected behaviour:
After digging around in the SPI code and the chip manual it seems transfer16 fails to properly reset the TCR register value after modifying the FRAMESZ bits.
If I understand correctly this is caused by a problem with reading this register as described in 48.4.1.15.2 of the manual:
The register write of the first transfer16 call is still stuck on the FIFO when the second call reads TCR so the FRAMESZ bits are still set to 15.
So the second call incorrectly resets the FRAMESZ bits to 15 instead of 7.
I am unsure about a possible fix though:
I hope someone with a bit more experience can weigh in on this
while trying to address an external eeprom module from a Teensy 4.0 I noticed some strange behaviour of the SPI library functions transfer/transfer16:
The SPI interface seems to get stuck with a 16 bit frame size after two consecutive calls to transfer16. Following calls to transfer
now clock out 16 bits instead of the expected 8.
I managed to reproduce this behaviour with the following code snipplet:
Code:
SPI.beginTransaction(SPISettings(115200, MSBFIRST, SPI_MODE3));
digitalWrite(21, LOW);
SPI.transfer16(0x00FF);
SPI.transfer16(0xFF00);
SPI.transfer(0xAA);
digitalWrite(21, HIGH);
SPI.endTransaction();
See the extra 0x00 before sending 0xAA:
Commening out one of the calls to SPI.transfer16 I get the expected behaviour:
After digging around in the SPI code and the chip manual it seems transfer16 fails to properly reset the TCR register value after modifying the FRAMESZ bits.
If I understand correctly this is caused by a problem with reading this register as described in 48.4.1.15.2 of the manual:
The register write of the first transfer16 call is still stuck on the FIFO when the second call reads TCR so the FRAMESZ bits are still set to 15.
So the second call incorrectly resets the FRAMESZ bits to 15 instead of 7.
I am unsure about a possible fix though:
- Use the strategies suggested in the manual to avoid the read problem
- Reuse the TCR value from SPISettings
I hope someone with a bit more experience can weigh in on this