How the SPI Peripheral Generates Its Clock Line

Today I finally figured out how to use the SPI peripheral.

Let's discuss it with these three typical APIs:

Transmit: HAL_SPI_Transmit_DMA(Spi, RBuf, ui32Len)
Receive: HAL_SPI_Receive_DMA(Spi, RBuf, ui32Len)
Transmit/Receive: HAL_SPI_TransmitReceive_DMA(Spi, RBuf, ui32Len)

A problem I ran into earlier

When operating as an SPI master, calling the receive API never actually got me any data, so I used the transmit/receive API everywhere I needed to receive.

I don't use SPI much, and the use case has always been simple, so I never really thought about why. I just assumed it was a problem with the API implementation (there's a compatibility layer wrapped around the lower level, after all).

Rewriting the SPI flash driver today made me pick the question up again.

In short

SPI is a hardware communication protocol that shifts data on the edges of the clock line. Without a clock, neither the master nor the slave actually sends anything—unless it's some weird non-standard implementation.

And normally, only the master is allowed to generate the clock.

So the answer is obvious: at least on STM32, the clock is only generated while transmitting. That means even a pure receive still has to use the transmit/receive API.

The receive API only makes sense when acting as a slave, or in the case GPT mentioned where external hardware generates the clock (which sounds terrifying—does anyone actually do that?).

Thoughts

SPI communication seems suited to bidirectional communication without exception, and not to one-way communication. That becomes a problem when you're a master trying to do a large read, because the transmit side still needs a buffer of the same size.

It might be an STM32 HAL implementation issue, but I haven't looked into it. I'll deal with it if I actually run into it.

Conversation with Copilot (discussing SPI clock and receive implementation)

Date: 2026-01-21 · Participants: stbanana (user), Copilot (assistant)

stbanana

If I want the clock to be generated when I call a certain API, is there a configuration for that? And if that still requires using the transmit/receive API, then when I only need to read, the TX side still has to occupy a buffer, which might cause some problems.

Copilot

Done: Recommending SPI read approach

You can, but you need to distinguish between “hardware automatically supplying the clock” and “software explicitly supplying the clock.” Given your current STM32H743 + HAL configuration, here's the conclusion:

1) Does pure reception also automatically generate the clock?

In master mode on the STM32H7, by default, no.

HAL_SPI_Receive_DMA()

only enables RX DMA; it doesn't actively drive TX, so normally no clock is generated.

Some frameworks/library functions may automatically send dummy data during RX-only operations (your current code doesn't).

2) Ways to make it work (recommended)

Keep using

HAL_SPI_TransmitReceive_DMA()

, but give it a dummy TX buffer.

This buffer doesn't need to be large, and it doesn't need to be dynamically allocated. Options:

A permanent TX buffer (e.g., always

0xFF

or similar), sent repeatedly in blocks;

Single-byte + DMA, with TX DMA's

MemInc

disabled, to repeatedly send the same byte.

3) “Will occupying a buffer cause a problem?”

Usually not. You already have

fspiTxBuf

; just use it for pure dummy transmission.

The key is that the clock must stay enabled for the entire CS period, so TX has to be present.

If you're worried about using up a large buffer, you can:

Transmit/receive in chunks;

Make the dummy buffer a fixed single byte and reuse it in a loop.

Recommended implementation (most compatible with your current code)

Keep the existing

TransmitReceive

+ dummy approach.

If some API in the future also supplies the clock automatically, you can change

FlashSpiReceivePort()

to call

SpiTransmitReceive()

internally, and use a fixed dummy buffer inside so callers don't have to worry about TX.

stbanana

No, the code I'm using right now is only about

spiflash

; it's not a unified/general-purpose approach. My

spistdio

is meant to provide the most general usage. Please stop focusing on the prot function wrapper around my

spiflash

and focus on the STM32 SPI implementation.

Copilot

Done: Acknowledging request and outlining response

Got it — I'll focus only on the STM32 SPI implementation itself. Here's the approach and conclusion.

Approach

Explain where the clock comes from in STM32H7 SPI master mode;

Explain how

HAL_SPI_Receive_DMA

behaves differently in master/slave mode;

Offer reasonable design suggestions at the “generic SPI stdio” level.

Conclusion

In STM32 master mode, the clock is actively generated by the master; usually only TX or full-duplex operations drive SCK.

HAL_SPI_Receive_DMA()

does not guarantee clock generation in master mode, so it can't serve as a generic “read-only” interface (unless the hardware/library supports automatic RX-only clocking) — which isn't present in your current configuration.

In slave mode,

HAL_SPI_Receive_DMA()

makes sense, because the clock comes from an external master.

Suggestions for a “generic SPI stdio”

Keep

SpiReceive()

as the API semantics, but internally switch to “dummy TX + RX” (full-duplex) in master mode to guarantee the clock;

Only in slave mode does

SpiReceive()

use true RX-only;

This keeps the external interface consistent: stable semantics, while the clock strategy is chosen internally based on master/slave mode.

If you want, I can give a “master/slave adaptive” implementation of

SpiReceive()

based on your existing

spistdio.c

framework (without touching the specific spiflash logic).

stbanana

That doesn't seem like much of an improvement, so let's keep things as they are for now.