HAL_SPI_TransmitReceive_IT(...) forgets to __HAL_UNLOCK(hspi) before __HAL_SPI_ENABLE_IT(hspi, ...)

[MD.8]

This occasionally leads to (especially if only transferring one byte) the interrupt executing before the function has unlocked the process, leading to the function returning HAL_BUSY if you were to attempt to initiate another transfer in the transfer complete callback.

Same goes for HAL_SPI_Transmit_IT(...) and HAL_SPI_Receive_IT(...).

HAL_SPI_Receive_IT(...) even has this comment:

/* Note : The SPI must be enabled after unlocking current process

      to avoid the risk of SPI interrupt handle execution before current

      process unlock */

but then proceeds to not follow its own advice. So I think the unlock was accidentally removed at some point.

This bug is present in latest versions of STM32F0, STM32F4, STM32L0, STM32L4 firmwares at the very least.

[Piranha]

The whole idea of that lock is flawed by design because it doesn't provide neither interrupt, nor thread safety. Also returning "busy" in ISR... What are you supposed to do then? Wait? And the implementation is also broken:

https://community.st.com/s/question/0D50X0000C5Tns8SQC/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe

That's what we get when the developer team consists of incompetent "developers".

[MD.8]

Yep, if your main loop (or a lower priority interrupt) is in the middle of a call to HAL_***_IT() and a higher interrupt starts running and tries to call HAL_***_IT() that is a bug in your code. Your code should ensure that it will never attempt to interlace calls to the function. If you are in interrupt context and HAL_***_IT() returns HAL_BUSY, it is never not going to return HAL_BUSY until you leave the interrupt, there's no point in trying to wait. About the only thing the locking mechanism is good for is catching this specific bug. But since it's not even implemented correctly (and bugged) it's just in the way.

[GSchw.2]

Hello,

Can this issue also be causinig NSS to toggle and bounce in between TxRx? I have been using the HAL_TxRx in polling mode works fine, however, in IT mode, my NSS signal is bouncing many times in between TxRx.

Never had this issue before with other vendors. Like I said in polling works fine, in IT. I get this.