Skip to main content
E
Ernest Lotter
Visitor II
August 14, 2020
Solved

STM32F4xx and STM32H7xx CUBE HAL SPI BUGS

  • August 14, 2020
  • 2 replies
  • 1128 views

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.

    This topic has been closed for replies.
    Best answer by Radek RIPA

    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

    2 replies

    R
    Radek RIPAAnswer
    ST Employee
    August 27, 2020

    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

    E
    Ernest LotterAuthor
    Visitor II
    August 28, 2020

    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.

    Terms & ConditionsAccessibility statement