STM32F205 SPI1 in master mode, why is clock left floating at end of transfer?

[GGatl.1]

Using HAL_SPI_Recieve(), SPI1 Master, 8-bit transfer, 3 consecutive bytes. At end of 24th clock pulse, the pin bounces up to a middle voltage and then decays to zero. Pull down resistor helps, but not enough. Screenshot of problem attached. How do I fix this? / Why is it happening?

Note, also using SPI3 in an identical way and this does not happen. Only SPI1. (SPI2 is busy with other things and I can't really test whether this happens on SPI2.)

[waclawek.jan]

> Why is it happening?

Because you use Cube/HAL function, which disables SPI after end of transfer.

That explains the decay. I don't know what's the cause of the "bouncing up", but I'm not going to investigate Cube code.

> also using SPI3 in an identical way and this does not happen.

Who knows what you do in combination with Cube's code.

JW

[GGatl.1]

Is cube code generally thought to be buggy like this? I've never used it before this project. I'd rather not spin my own SPI library from the ground up... are there more trusted alternatives for the STM32F2's?

[waclawek.jan]

It's not buggy, this is simply how it behaves.

As with any "library" and any "abstraction", it inevitably implements only a fraction of the hardware's features, in what the authors deemed "usual usage". Most of the people are probably OK with the SPI signals being threestated outside the transmission window, probably framed by some slave-select signal or something similar. In exchange for the limited number of usage modes, you get the clicky (CubeMX), ready-made examples, and a promise of easy migration to other STM32 models/families.

There's also the Cube/LL, which is mostly a rename of the registers, marketed as middle ground between Cube/HAL and register-level access. There's some clicky support for that, too.

It's upon you whether you are happy with this, or you want to exert more control.

As it may have perspired, I don't use Cube.

JW

PS. Cube is open source, so you can freely observe how it works, and you can also get inspired.

[TDK]

This behavior is a byproduct of the awkward way receive only master mode is implemented in hardware.

Use HAL_SPI_TransmitReceive instead and leave the MOSI pin uninitialized.

[GGatl.1]

Awesome! Works perfectly. Thank you