Bug in STM32L4xx_HAL_Driver (SPI Transmit)

[vladimir2]

Posted on March 21, 2016 at 13:30

Component: STM32L4xx_HAL_Driver

File: stm32l4xx_hal_spi.c Function: HAL_SPI_Transmit Line number: 519 Description: SPI RX FIFO not empty after transmit. Solution: Remove

{

__HAL_SPI_CLEAR_OVRFLAG(hspi); } Insert

{

__IO uint32_t tmpreg; tmpreg = hspi->Instance->DR; while ((hspi->Instance->SR & SPI_FLAG_RXNE) == SPI_FLAG_RXNE) { tmpreg = hspi->Instance->DR; /* read the received data */ } tmpreg = hspi->Instance->SR; UNUSED(tmpreg); } Note: please review all SPI code, it may containsimilar bugs. #stm32cubef3 #stm32cubel4 #bug #spi

[Walid FTITI_O]

Posted on March 22, 2016 at 12:38

Hi kurilovich.vladi.001,

Thanks for your feedback. I will check this internally . -Hannibal-

[mklatt9]

Posted on September 30, 2016 at 13:55

I can confirm this bug also for STM32CubeF3 in Version 1.4.0 and 1.6.0 (current). I suppose this code is used in F4 and other packages too... :( .

The provided code solves the problem in this function. A TransmitReceive is erroneous after a Transmit. Transmit handles the DR register not correct. Please hurry up, Hannibal 🙂 . Please confirm and fix... Thanks. MK

[Walid FTITI_O]

Posted on September 30, 2016 at 17:42

Hi mk@sch, 

It is already confirmed and fixed in the new release ( as STM32L4). A new release of STM32CubeF3 is not done yet. Meanwhile, you can do the following workaround:

You need to flush the fifo when an incorrect transfer is detected: Before the end of an implemenation, use the specific function HAL_SPIEx_FlushRxFifo when this kind of situation is detected.

-Hannibal-

[mklatt9]

Posted on October 05, 2016 at 12:27

Hi Hannibal,

thanks for pointing that out. And once more there is a lack of information and a lack of a common bug tracker. I feel my time wasted with debugging someones (more or less tested!?) code, for which a bug is already confirmed and fixed - but in another package. I hope ST will strengthen the team around the CubeMX project and changes their dev and release strategy with better testing and bug management. This is a piece of helpful software - but if it saves time at one point (and it does!), it's sad to waste this time with discovering bugs in some very common functionalities. About your work-around idea: Your solution has nothing to do with the problem this thread is about. True, it's about the fifo but there is a misuse of it after a Transmit which results in a wrong reading of data in a subsequent Receive (which calls TransmitReceive). The Transmit doesn't detect an incorrect transfer. The provided code at the top changes the fifo behavior and it works now. Perhaps we talk about two different bugs in this HAL section. Please check, confirm and fix this soon at all affected packages. Thanks, MK

[Amel NASRI]

Posted on January 23, 2017 at 17:25

Hello,

I would like to come back to this reported issue.

If I check how

__HAL_SPI_CLEAR_OVRFLAG is implemented:

/** @brief Clear the SPI OVR pending flag.
 * @param __HANDLE__: specifies the SPI Handle.
 * This parameter can be SPI where x: 1, 2, or 3 to select the SPI peripheral.
 * @retval None
 */
#define __HAL_SPI_CLEAR_OVRFLAG(__HANDLE__) \
 do{ \
 __IO uint32_t tmpreg_ovr = 0x00U; \
 tmpreg_ovr = (__HANDLE__)->Instance->DR; \
 tmpreg_ovr = (__HANDLE__)->Instance->SR; \
 UNUSED(tmpreg_ovr); \
 } while(0)�?�?�?�?�?�?�?�?�?�?�?�?

This is aligned with the description in the reference manual on how to manage Overrun case:

When an overrun condition occurs, the newly received value does not overwrite the previous one in the RXFIFO. The newly received value is discarded and all data transmitted subsequently is lost. Clearing the OVR bit is done by a read access to the SPI_DR register followed by a read access to the SPI_SR register.

So I would like to get more details on the faced issue: when exactly does it occur?...

-Amel