SPI transmit not works as expected

[rickou]

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]

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]

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.

[KRASTM]

Hello @rickou,

Regarding the issue, I checked with our team and as explained before, there is no plan to implement the workaround within the driver. For your question, it's not easy to mention or to give the delay and/or the ratio because these values depend on many parameters within the application. Please allow me to close the thread.

Thank you in advance for your comprehension.

With regards,

[rickou]

Hello @KRASTM , ok, but please allow me to be not satisfied of this answer at all...

I understand the difficulty to implement the workaround Also I can easily understand there is many parameters to determine the delay/ratio for the errata...

But microcontrollers are deterministics (at least for digital synchronous interfaces !) made only 1 or 0.. works or not... When I write a deterministic source code (for a SPI which is very deterministic) I just want to be sure, it will works... not only during the dev phase on the desk...

Today I use a clock derived from MSIK with a ratio of 1:1 which should works 100% time The errata suggest we can use other low ratios.. I understand i could also use the nearest ratio of 1:2.... or 1:3 ?? (this could allow to improve other peripherals performances) But if no-one in ST could confirm these ratio will works... why simply not writing "only 1:1 ratio allowed"...

othewise it is the same as if it is written "maybe it will works, maybe not.."...

Best regards.