Bug(embassy_stm32): SPI Clock stuck at start and end of transaction for STM32F439ZIT6U

[vpochapuis]

What

When using emabssy_stm32 on a STM NUCLEO-F439ZI (STM32F439ZIT6U) with the SPI3, for several hundreds of microseconds at the start and end of a transaction the clock will be respectively stuck high and low while the transaction will happen normally for the remaining bits.

Issue POC

Here is a repo summarizing and giving some code to reproduce the issue
https://github.com/vpochapuis/embassy-stm32-spi-bug-trigger/tree/master

[rmja]

If you zoom in on the actual transmission, does the clk not align correctly right before bits are actually transmitted?

[vpochapuis]

Sorry for the late reply.

It seems like the issue happens only when the program is run using probe-rs run, hence might not be related to the HAL or embassy but to probe-rs interaction with the board.

This is a new reading from probe-rs run:

And here is a reading after restarting the board manually without probe-rs attached:

I am not sure how can probe-rs affect SPI communications as such, and I would like some help to confirm that its only due to probe-rs and not the HAL.

[vpochapuis]

I will close this issue as it seems like its about a wrong gpio pin selection for the spi clock on the board I am using.
The Pin is also the pin used for the ST-Link debugger, hence interfering when the debugger is used.
The resource that let me on the path on understanding: https://community.st.com/t5/stm32-mcus-products/st-link-stoppes-spi-clock/td-p/411622.

Sorry for the issue opening that wasn't due to this crate.

(Edit:
Indeed, after changing from PB3 to PC10 following the alternative pins implementing clock for this SPI peripherals here https://docs.embassy.dev/embassy-stm32/git/stm32f439zi/spi/trait.CkPin.html , the clock is working correctly during debug
)