LPSPI in master mode transmitting endlessly on CONT + CONTC command if TXMSK is set

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

LPSPI in master mode transmitting endlessly on CONT + CONTC command if TXMSK is set

Contributor II

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:

  1. send/receive 8 bits
  2. receive 32 bits
  3. 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):

  1. TCR = { CONT = 1; FRAMESZ = 7 (among CPOL, PCS etc.) }
  2. TDR = byte to be sent
  3. TCR = { CONT = 1; CONTC = 1; TXMSK = 1; FRAMESZ = 31 }
  4. 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?

Labels (2)
Tags (1)
0 Kudos
2 Replies

Contributor III

Hello @Mysterion,

did you ever find a solution to that problem?

I currently have the same problem but a bit worse: I want to use QSPI and therefore have to set TXMSK. Therefore I can't use the workaround to push one dummy byte to the TDR for each data that should be read. Due to some errata on the i.MXRT1050 related to TXMSK and TCR, I also can't just push the next TCR into the FIFO. ERR011097 tells that the FIFO should be empty before pushing another TCR if TXMSK is set. ERR050607 tells that I have to either wait for the transfer to be complete or I have to split a transfer into multiple commands. Together with the endless transmission that you describe, I haven't yet found a method to fulfill all these requirements without a lot of polling and hoping that I get the timing right.

Best regards


0 Kudos

Contributor III

I think I just found my answer: NXP has a application note for the LPSPI on KL28Z. There is a paragraph regarding that problem:

3.3.4. 4-bit dummy operation in continuous mode
If use dummy operation in continuous mode, need to pay attention, LPSPI would not stop after the
frame length specified in TCR is sent out. So, for 4-bit dummy operation, continuous mode is not
recommended. So, to implement 4-bit operation, need to work in non-continuous mode and implement
CS by GPIO mode.

Dummy mode in this case is a transfer with RXMSK and TXMSK set. I assume it's the same for the LPSPI on i.MXRT1050 and only TXMSK set. Seems that the LPSPI module is just broken and can't handle the CS pins like expected.

@Mysterion: Sorry for bothering you. Should have searched a bit more before replying to your old post.

0 Kudos