STM32 SPI half-duplex 5-bit read clocks excess bits after split write/read (expected 20 bits, observed ~40-50 bits)

[Kusekushi]

Hi all,

On an STM32G0C1 (custom board, but only 1 SPI slave), SPI half-duplex transfers with 5-bit word size show excess clocking during read phase when doing any transaction:

i.e.
spi_write_dt for 1 frame (5 bits command)
spi_read_dt for 4 frames (20 bits data)
under one manual CS window.
With this example I expect total clock pulses to be 25 bits and thus, often enough, leads to an OVR condition.

Though I see approximately 40 to 70 bits on receive phase, depending on the SPI bus speed among other things, while software buffer/accounting indicates intended frame count.

This behavior only occurs when enable debug logs on UART...
If I transmit only, the peripheral works as intended.

Target Platform

• MCU: STM32G0C1
• SPI peripheral: SPI3
• Slave device: RTC6715 (LSB-first, half-duplex, 5-bit words, 25-bit transactions)
• Zephyr 4.4.0, SDK 1.0.1

What I tried already:

• Single-call transceive path for combined TX/RX.
• Seperate send/recv calls
• Separate SPI config objects for TX and RX to force full reconfigure between calls.
• Software CS (manual control and polarity handling).
• spi_release_dt calls between write and read.
• Interrupt mode adjustments (including polling-style config choices).
• Logging level changes (issue sensitivity observed with high log verbosity).

Reproduction steps:

1. Use SPI node configured for:

• master mode
• half-duplex
• LSB-first
• 5-bit words

2. Use manual GPIO CS (disable auto CS in spi config and control CS directly).
3. Hold CS active for full read transaction.
4. Call spi_write_dt with 1-byte buffer representing one 5-bit command frame.
5. Call spi_read_dt with 3-byte buffer representing three 5-bit receive frames.
6. Deassert CS.
7. Observe SCK with scope or logic analyzer.

Log output:
[0m[00:00:00.010,000] [0m spi_stm32: spi_context_buffers_setup: current_tx 0x2000944c (1), current_rx 0 (0), tx buf/len 0x20009454/1, rx buf/len 0/0[0m
[00:00:00.010,000] [0m spi_stm32: spi_context_update_tx: tx buf/len 0/0[0m
[00:00:00.010,000] [0m spi_stm32: spi_context_buffers_setup: tx_bufs 0 - rx_bufs 0x20009430 - 1[0m
[00:00:00.011,000] [0m spi_stm32: spi_context_buffers_setup: current_tx 0 (0), current_rx 0x20009438 (1), tx buf/len 0/0, rx buf/len 0x20009440/3[0m
[00:00:00.011,000] [0m spi_stm32: spi_context_update_rx: rx buf/len 0x20009441/2[0m
[00:00:00.011,000] [0m spi_stm32: spi_context_update_rx: rx buf/len 0x20009442/1[0m
[00:00:00.011,000] [0m spi_stm32: spi_context_update_rx: rx buf/len 0/0[0m
[00:00:00.011,000] [0m main: testvp: Read state register: 0x02[0m

DTC (shortened):

&spi3 {
	status = "okay";
	pinctrl-0 = <&spi3_sck_pc10 &spi3_mosi_pc12>;
	pinctrl-names = "default";
	cs-gpios = <&gpioc 11 GPIO_ACTIVE_LOW>;
	#address-cells = <1>;
	#size-cells = <0>;
	clocks = <&rcc STM32_CLOCK(APB1, 15)>;

	vrx_a: rtc6715_a@0 {
		compatible = "rtc6715";

		reg = <0>;
		spi-max-frequency = <250000>;
		duplex = <SPI_HALF_DUPLEX>;
		spi-lsb-first;
	};
};

(RTC6715 binding inherits from spi-device, so it should be fine)

Any idea what it could be? Is it my approach? Is it the chip being weird?

Logic analyzer on command write (expected result) Logic analyzer on response read (issue)

[gautierg-st]

Hello @Kusekushi,
I've just pushed PR #112253 that brings improvements to half-duplex support. If you have time, I would appreciate if you could take a look and see if it solves your issue.

[erwango]

@Kusekushi Did you had time to look at #112253 ?