I'm experiencing some strange behaviour when trying to communicate as SPI master via LPSPI on a i.MXRT 1062 MCU, when making use of continuous transfer commands (TCR.CONT and TCR.CONTC set) combined with TCR.TXMSK.
The communication sequence desired:
- send/receive 8 bits
- receive 32 bits
- receive 16 bits
This means for implementation (pseudo code; of course, the command word ist prepared and then written to TCR in an atomic way):
- TCR = { CONT = 1; FRAMESZ = 7 (among CPOL, PCS etc.) }
- TDR = byte to be sent
- TCR = { CONT = 1; CONTC = 1; TXMSK = 1; FRAMESZ = 31 }
- TCR = { CONTC = 1; TXMSK = 1; FRAMESZ = 15 }
Unexpectedly, after the second TCR access (step 3), the transfer is starting immediately, but doesn't stop after 32 SPI clocks, but keeps on clocking endlessly (clearly reproducible with CR.DBGEN set, executing until step 3, and halting after the TCR write access).
Subsequently, the RX-FIFO does overrun, even though CFGR1.NOSTALL is not set (meaning, the transfer should stall when the receive FIFO is full).
The issue does not seem to occur, if
- the next command (see step 4) is pushed to the TX FIFO, before the liable command is executed (nur 100% sure about that)
- TCR.TXMSK is not used, providing dummy data via TDR instead (my current workaround)
For me this looks like a LPSPI issue. However I could not find any hint in the RM, or in the chip errata.
Is there any better solution instead of the workaround?