Describe the bug

On MIMXRT1062, using spi_transceive on an LPSPI peripheral, one word more is clocked out than requested.
This leads to issues with peripherals that are very picky about transmission lengths, e.g. TMC5041 in our case.

To Reproduce

• Build a shell module e.g. for MIMXRT1062-EVKB with CONFIG_SPI_SHELL=y and CONFIG_SPI=y
• Use LPSPI "CPU driver" (not DMA)
• Record traces of MISO, MOSI, SCK, CS
• Run the shell commands spi conf lpspi4 400000 and spi transceive 00 00 00 00 00
• Traces show one word more than requested (see Logs and console output)

Expected behavior

spi_transceive only clocks exactly the number of words requested.

Impact

Currently not a showstopper as a patch is known:
After bisecting the issue to e086678 and some trying around, I found that spi_transceive worked normally again when, in https://github.com/zephyrproject-rtos/zephyr/blob/21b20de1eb346ab6f5264f6596b3d93ff93c65e5/drivers/spi/spi_nxp_lpspi/spi_nxp_lpspi.c#L264C1-L282C3 , the "stalling behavior end xfer workaround" is moved before the FIFO queue fill, or the FIFO queue fill is removed entirely. The fact that the VERID check on main is currently bugged is a separate issue which is already addressed in #90182 .

Logs and console output

1. On 21b20de
   Shell output:

uart:~$ spi transceive 04 00 00 00 00
TX:
00000000: 04 00 00 00 00                                   |.....            |
RX:
00000000: 00 00 00 02 00                                   |.....            |

Logic analyzer trace:

2. With "change of order" patch described above

Shell:

uart:~$ spi transceive 04 00 00 00 00
TX:
00000000: 04 00 00 00 00                                   |.....            |
RX:
00000000: 00 10 00 00 05                                   |.....            |

(this is the correct response to the SPI command)

Environment (please complete the following information):

• OS: Linux
• Zephyr SDK 0.17.0
• Commit 21b20de