STM32H730 SPI clock (SCK) bug

[KubeckPL]

Hello. I have noticed a SCK clock error on the SPI bus in the STM32H730 processor (own board). It may be due to the HAL library I am using (v1.10.0), STM32CubeIDE V1.10.

My SPI configuration (SPI2 in this case) in CubeMX:

I use SPI in Polling Mode. I send 8 bits of data using the function: HAL_SPI_TransmitReceive(). The SPI clock is relatively small (about 6kHz). The problem is that the last clock lasts much shorter than the other seven, as shown by the SCK line dump from the oscilloscope:

The probable cause of this behavior may be the implementation of the HAL_SPI_TransmitReceive() function. File stm32h7xx_hal_spi.c, line 1217. This function, after copying and reading data to/from the SPI registers in a while() loop, waits for the EOT flag in the SF register to be reset. Immediately after resetting the EOT flag, the SPI_CloseTransfer(hspi) function is called, which shuts down the entire SPI module. I think that disabling the SPI module at this point may be the reason for the short duration of the last clock tick. The second possibility is that the EOT flag is not in the high state at all.

For testing purposes, I added a 1ms delay in the program code between waiting for the EOT flag to reset and calling the SPI_CloseTransfer(hspi) function. This delay caused the last clock to take the same amount of time as the other seven. Unfortunately, after rebuilding and re-generating the project in CubeMX, my piece of code was removed from the function.

Is it possible to configure the SPI module in such a way as to work around the above problem? Is the error actually due to the SPI driver implementation in the HAL library? Could the error be due to poor handling of the EOT flag in the SR register?

Best regards, Kuba.

[HBOSTM]

ST Internal Reference: 139534

[HBOSTM]

Hello @KubeckPL ,

First of all, thank you for this contribution. After extensive investigation by our development team, here is the answer: The potential problem could rise only if either the last SCK pulse or associated data hold time (measured from the last SCK sampling edge to the moment the SPI is disabled by SW once active EOT flag is detected) provided master is too short and a very slow slave has problems just with correct sampling of the last bit (slave can possibly oversee the short SCK pulse or perform a late sampling of the data bit value on its input.). At this specific case only, user has to adopt some workaround and postpone the SPI disable action at master side by inserting an additional SW delay between EOT detection and SPI disable itself. Please come back to me if there are other contributions.

Best Regards,