STMicroelectronics / stm32u5xx_hal_driver

Provides the STM32Cube MCU Component "hal_driver" of the STM32U5 series.
BSD 3-Clause "New" or "Revised" License
7 stars 11 forks source link

SPI transmit not works as expected #13

Open rickou opened 1 week ago

rickou commented 1 week ago

the SPI transmit transaction do not ends correctly.

I use the latest ST U5 package in my project, and i'm facing this problem when optimizing the build. (-O3)

Without optimization it works but as soon as i set some optimization the code is much fast and the transaction is aborted before the end. if i put a breakpoint just before the SPI_CloseTransfer(hspi); line 1024 of stm32u5xx_hal_spi.c, then the transaction is completed as expected.

The errata of STM32U5A5 mention Truncation of SPI output signals after EOT event under certain circumstances. https://www.st.com/resource/en/errata_sheet/es0553-stm32u59xxx-and-stm32u5axxx-device-errata-stmicroelectronics.pdf §2.18.7

It could be great ST to add the ST's suggested workaround in HAL driver !

as a reference linux kernel add this workaround... https://lore.kernel.org/linux-arm-kernel/20230906132735.748174-1-valentin.caron@foss.st.com/T/

KRASTM commented 6 days ago

Hello @rickou,

Thank you for the repot.

In fact, that's the purpose of the errata sheet. When a problem is already mentioned with a workaround, it means our team has decided not to implement the solution within the driver for various reasons, such as, avoiding impact on the driver's performance, because it is a particular case, or because the phenomenon appears under certain circumstances.

However, I shared your proposal with our team in order to analyze more and I will keep you informed.

Just to be sure, you are using Cube IDE?

With regards,

rickou commented 6 days ago

hi

thank for the feedback, I lost many hours to understand why my SPI device do not works as expected once i enable the build optimizations... searching deep into the HAL put me on the way... but all this time lost !

For me, the main advange of the HAL provided by ST is to make implementation of the differents modules in order to they works fine. (including the workarounds, at least by using preprocessor defines for example...)

I "solved" my case modifying the clock of the SPI to get closer to the input clock. note: to be honest, the Errata is not clear about the workaround... "Add a delay between the EOT event and SPI disable action.", ok but how much ?? "Decrease the ratio between PCLK and SCK frequencies.", ok, but which ratio is acceptable ??

If i was not able to change the SPI module input clock, the HAL SPI module is not usable at all, because there is no way to insert delay between last byte sent and peripheral stop..

yes i'm using cubeIDE, but not the UI configuration wizard.