cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4xx and STM32H7xx CUBE HAL SPI BUGS

Ernest Lotter
Associate II

High Level Problem Description:

STM32F4xx:

Produced on STM32F427IIHx

What happens:

When SPI as master, full duplex, 8 bit & ~1MHz clock speed and doing longer transmissions (e.g. 10 - 60 bytes) using interrupts the current implementation in Keil::STM32F4xx_DFP V2.14.0 produces RX overrun error.

Why (after investigation):

The TX empty interrupt can fire in succession without RX not empty being flagged. This means there is not time to empty the receive register in time to avoid overrun condition. In other words, the silicon implementation does not guarantee interrupt flags/interrupts will respond in time to avoid overrun condition.

Proposed conceptual fix (verified):

Disable TX empty interrupt after transmit until receiving corresponding data then enable again, unless all data has been received (end of transmission).

STM32H7xx:

Produced on STM32H743BITx

What happens:

When SPI as master, full duplex, 8 bit & ~1MHz clock speed and doing longer transmissions (e.g. 10 - 60 bytes) using interrupts the current implementation in Keil::STM32F4xx_DFP V2.14.0 produces RX overrun error.

Why (after investigation):

The TXP interrupt can fire in succession without RXP or DXP being flagged. This means there is not time to empty the receive register and or FIFO in time to avoid overrun condition. In other words, the silicon implementation does not guarantee interrupt flags/interrupts will respond in time to avoid overrun condition.

In my specific use case sending bytes, when the available FIFO buffer is filled (when hspi->RxXferCount - hspi->TxXferCount > 7) further data transmission often typically/often result in the overrun condition.

Proposed conceptual fix (verified):

Disable TXP interrupt after transmitting to right before the limit of FIFO (configuration dependent) until receiving enough of the corresponding data then enable again, unless all data has been received (end of transmission).

I am happy to provide more specifics/code on the proposed fix once this tickets is looked at and more details are required.

1 ACCEPTED SOLUTION

Accepted Solutions
Radek RIPA
ST Employee

Hello,

I can confirm your findings.

For both devices. Which have same error, where is not counted with situation that is additional content in shift register. If SPI IRQ is delayed the overrun is caused as result.

Im reporting this to our SW team to fix this issue for future releases.

Best regards

Radek

View solution in original post

2 REPLIES 2
Radek RIPA
ST Employee

Hello,

I can confirm your findings.

For both devices. Which have same error, where is not counted with situation that is additional content in shift register. If SPI IRQ is delayed the overrun is caused as result.

Im reporting this to our SW team to fix this issue for future releases.

Best regards

Radek

Ernest Lotter
Associate II

Hi Radek,

Thanks for looking at my report.

Please note that the issue is further spread than F4 and H7 that I reported on. I know for a fact that it is also a problem on the F2. I imagine its very likely a problem on all Cube HAL libraries for families using the same SPI silicon implementations as F2, F4 & H7.