SPI generates too many clocks in Bidirectional mode

[dsabala]

Describe the set-up

• Bidirectional SPI, high clock frequency, SPI device with FIFO registers (STM manufactured accelerometer)

Describe the bug
Function HAL_SPI_Receive generate clock on SPI clock line a few octets too long, for example reading 6 octets generates 9 octets of clock, thus transmissions "with side effect" like for example reading FIFO from accelerometer can result in extremely confusing bugs

More detailed info:
http://efton.sk/STM32/gotcha/g32.html

How To Reproduce
Setup bidirectional SPI working at high clock and observe MISO/MOSI line with logic analyzer, use CubeMX autogenerated code.

Additional context
Instead of fixing it you can inform CubeMX users of the problem or even remove bidirectional SPI choice from CubeMX

[KRASTM]

Hello @dsabala,

Thank you for the report.

Could you please share more details about this phenomenon (scrennshot with or from logic analyzer and a snippet of code for the transmit or receive function), and your IOC file for further analysis. In the meantime, we will try to check with our team.

With regards,

[KRASTM]

Hello @dsabala,

Any news please?

With regards

[dsabala]

Hello @KRASTM

I solved the problem by creating a custom SPI driver that manages half-duplex SPI communication without introducing unnecessary SPI clock cycles. I used HAL LL (low layer) routines to configure the SPI and TIM peripherals to the desired states.

The key aspect of the solution is disabling the SPI peripheral within a very strict timing regime. To achieve this, I utilized a high-resolution hardware timer configured in single-pulse mode. The timer is set to trigger an interrupt after a duration equal to the time required for transmitting a single byte * (number of bytes - 0,5). Within the timer interrupt handler, the SPI peripheral is disabled.

The entire read transfer is executed in a "subcritical" section by using the basepri register, ensuring that only the timer interrupt remains enabled during this process.

Below are the results of reading measurements from the LIS2MDL magnetometer. The device is expected to receive 6 bytes, and while it does receive these 6 bytes, it continues to emit clock signals for an additional 3 cycles. If you are reading registers with side effects, such as FIFO registers in another STM MEMS sensor, this behavior could lead to difficult to debug bugs.