spi: H7 and F7 send bytes back to back, and two H7 transfer faults fixed

[MrScothh]

On H7 and F7 an SPI transfer sent a byte, then waited for its echo before sending the next, so the clock stood idle between bytes about as long as it ran. A register access also took two transfers, the address and then the data; on H7 each one is enabled, sized and closed on its own.

What changes

H7 and F7:

• Bytes back to back. The next byte goes out while the previous ones are still coming back, with at most two in flight.
  • Two already keep the clock running without a gap; four and eight measured no faster.
  • The receive FIFO holds 4 bytes on F7, 8 on H7 SPI4-6 and 16 on H7 SPI1-3, so with two in flight it cannot overflow whatever an interrupt does to the loop. The clock stops by itself when there is nothing left to send.
• One transfer per register access. busRead(), busReadBuf(), busWrite() and busWriteBuf() send the address and the data in one transfer.
• A timed-out transfer leaves the SPI ready for the next one. On F7 what is left in the FIFOs goes out and is read back and dropped, so the next transfer does not take it for its own.

F4 and AT32F43x are unchanged. Their SPI has no FIFO, only a data register. With a second byte in flight, an interrupt keeping the loop away for one byte's time (under 1 µs) would end in an overrun and a lost byte, so they keep sending one byte at a time.

Two H7 fixes the faster transfers needed. Both are in the current code, where they happen not to show:

• A speed change left the SPI enabled.
  • spiSetSpeed() re-enabled the SPI after changing its prescaler. An H7 SPI takes a transfer size only while disabled, so the first transfer after a speed change ran with the size of the transfer before it.
  • The current code gets away with it: every register access starts with a one-byte transfer, and the transfer before a speed change is usually one byte too.
  • With the address and data merged, the first gyro read after the ICM426xx init switched to BUS_SPEED_FAST ran with a size of 2 and stopped after two of seven bytes, once per boot on each gyro bus.
  • The SPI now stays disabled after a speed change, and each transfer disables it before setting its size.
  • The drivers that change speed at runtime (the SD card on SPI, the MAX7456, flash chips) could meet the same thing in the current code if the first transfer after a change is longer than the one before. I found no report of it.
• A timed-out transfer left the SPI enabled.
  • Every later transfer on that bus then had its size ignored and failed too, so one timeout took the bus down until a reboot.
  • I hit this on the bench while chasing the first fault: both gyros failed every read from then on and the main loop starved.
  • A timed-out transfer now disables the SPI, which empties its FIFOs, and clears its flags.
  • The wait for the end of a transfer, which had no limit, is bounded like the others.

Measured

Setup:

• TBS Lucid H7 Wing: two ICM-42688-P on SPI1 and SPI4 at BUS_SPEED_FAST (15 MHz), a MAX7456 on SPI2.
• A bench build with per-device bus timers that are not part of this PR. That build also carries spi: H7 ran SPI2-4, and F7 SPI4, at twice the clock asked for #12032, so SPI4 ran at the 15 MHz asked for rather than the 30 MHz of maintenance-10.x. The SPI1 figures do not depend on it.
• Averages over one minute, with the secondary gyro read continuously for the test.

	Before	After
Gyro read on SPI1 (address + 6 bytes)	7.9 µs	5.4 µs
Gyro read on SPI4	7.7 µs	5.5 µs
MAX7456 transaction, average	6.6 µs	5.2 µs
Time spent in primary gyro SPI	4.7 %	3.2 %

Bytes in flight, set at runtime in the bench build, SPI1 gyro read:

• 1: 7.7 µs. The single transfer alone saves 0.2 µs.
• 2: 5.34 µs.
• 4: 5.35 µs.
• 8: 5.36 µs.

Robustness:

• 30 boots: sensors detected every time, no SPI error. Before the spiSetSpeed() fix, every boot lost one transfer on each gyro bus.
• 10 minutes, board still: 6.2 million transfers, none lost. 2.43 million samples from each gyro, none above 100 °/s.
• The last 10 boots ran the final version. The other boots and the 10 minutes ran the H7 code as I first wrote it, before its loop was shared with F7; the H7 steps are the same.

Size against maintenance-10.x:

• TBS_LUCID_H7_WING: flash -96 B.
• MATEKH743: flash +320 B.
• MATEKF722: flash +96 B.
• MATEKF765: ITCM -56 B, flash +28 B, RAM +16 B.
• GEPRCF745_BT_HD: flash -400 B.
• MATEKF405: flash -384 B, RAM +16 B.
• BLUEBERRYF435WING: unchanged.

Not tested, testing wanted

Only one board ran this: an H743 with two ICM-42688-P and a MAX7456. F7 is built but untested: I have no F7 board. The F7 loop follows the reference manual (4-byte FIFOs, RXNE at 8 bits).

Wanted:

• Any F7 board. This is the part I could not try at all.
• Other H7 boards. Especially those with a different gyro (BMI270, ICM-42605, ICM-42686, MPU6000), a flash chip for blackbox, or an SD card on SPI (GEPRC_TAKER_H743, IFLIGHT_2RAW_H743).

What to check:

1. status shows the gyro, accelerometer, barometer and OSD detected.
2. The attitude in the Setup tab follows the board.
3. The OSD draws.
4. A blackbox log records and reads back, from flash or SD.
5. tasks reports a lower GYRO time than before.

A report of which board and what was checked is very welcome, even if everything simply works.

After review

• On F7 an aborted transfer waits for its queued bytes up to 1 ms instead of 1000 iterations, which at the slowest clock could end first.
• Register reads and writes return false when the transfer failed; like before this PR, they returned true whatever happened.

Built on F4, F7, H7, AT32 and SITL; KAKUTEF7 and KAKUTEF7HDV fit their ITCM. On the TBS Lucid H7 Wing (H7) the gyro reads are unchanged after review; the F7 abort path is untested (no F7 board).

Related PRs

• gyro: read the ICM426xx on its data-ready interrupt (H7) #12064 (gyro data-ready) builds on this one, and gyro: data-ready reads on F4 and F7 #12065, gyro: BMI270, ICM-45686, LSM6DXX and the MPU IMUs on data-ready #12066 and gyro: read the ICM426xx through its FIFO on data-ready (off by default) #12067 on that.
• Independent of spi: AT32F43x divisors, what they really run at, and an SD-safe initialisation clock #12048 (AT32 SPI clocks): this leaves F4 and AT32F43x as they are.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Pipeline H7/F7 SPI bytes and recover from transfer faults

✨ Enhancement 🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Send H7/F7 SPI bytes back to back and combine register addresses with data to reduce bus idle
 time.
• Reset H7 transfer state after speed changes or timeouts; drain F7 FIFOs after timeouts.
• Preserve F4 and AT32F43x transfer behavior because their hardware lacks a receive FIFO.

Diagram

graph TD
    A["Register APIs"] --> B{"MCU family"} --> C["H7 F7 engine"] --> D["SPI FIFOs"]
    B --> E["Legacy transfers"]
    C --> F["Timeout recovery"]
    G["Speed control"] --> C
    F --> D

Loading

High-Level Assessment

The shared, bounded polling engine fits short, synchronous register transactions while keeping the non-FIFO platforms on their existing path. DMA was considered, but its setup and coordination costs make it a poor fit for the measured short reads. F7 hardware validation remains the main outstanding check.

Files changed (3) +119 / -55

Enhancement (2) +22 / -8

bus_busdev_spi.cCombine register address and data on H7/F7 +19/-8

Combine register address and data on H7/F7

• Routes all four register read and write APIs through a single address-plus-data transfer on H7/F7. F4 and AT32F43x retain separate address and data transfers.

src/main/drivers/bus_busdev_spi.c

bus_spi.hDeclare the H7/F7 register transfer API +3/-0

Declare the H7/F7 register transfer API

• Adds the platform-guarded SPI register-transfer declaration used by the bus-device layer.

src/main/drivers/bus_spi.h

Other (1) +97 / -47

bus_spi_hal_ll.cPipeline SPI bytes and recover stalled transfers +97/-47

Pipeline SPI bytes and recover stalled transfers

• Shares a two-byte-in-flight transfer loop between H7 and F7, optionally sending a register prefix and discarding its echo. Bounds the H7 end-of-transfer wait, restores usable hardware state after timeouts, and leaves H7 SPI disabled after speed changes so subsequent transfer sizes take effect.

src/main/drivers/bus_spi_hal_ll.c

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. A timed-out bus sends stale bytes later 🐞 Bug ☼ Reliability

Description

spiTransferAbort() stops waiting after 1000 iterations even if the F7 transmit FIFO is still
nonempty or the bus remains busy, then drains only the receive FIFO. If that wait expires, the next
transfer can queue bytes behind the abandoned transfer, so its device receives old bytes before the
new command.

Code

src/main/drivers/bus_spi_hal_ll.c[R397-399]

+    for (int spiTimeout = 1000; spiTimeout && (LL_SPI_GetTxFIFOLevel(instance) != LL_SPI_TX_FIFO_EMPTY || LL_SPI_IsActiveFlag_BSY(instance)); spiTimeout--);
+    for (int n = 0; n < 8 && LL_SPI_GetRxFIFOLevel(instance) != LL_SPI_RX_FIFO_EMPTY; n++) {
+        (void)LL_SPI_ReceiveData8(instance);

Evidence

The new abort path bounds its wait without checking whether its exit condition was met, and its
remaining cleanup reads only RX data. The next F7 transfer sets the receive threshold and begins
transmitting without resetting or emptying the old TX state.

src/main/drivers/bus_spi_hal_ll.c[395-402]
src/main/drivers/bus_spi_hal_ll.c[426-440]
lib/main/STM32F7/Drivers/STM32F7xx_HAL_Driver/Inc/stm32f7xx_ll_spi.h[1010-1024]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The F7 abort path returns after its bounded wait even when queued transmit data or bus activity remains, allowing a later transfer to inherit stale bytes.
## Fix Focus Areas
- src/main/drivers/bus_spi_hal_ll.c[395-402]
- src/main/drivers/bus_spi_hal_ll.c[426-439]
## Recommended Fix
After the wait, check whether the transmit FIFO is empty and the bus is idle. If either condition persists, reset or reinitialize the F7 SPI peripheral and clear its pending receive/error state before allowing another transfer; keep the normal drain path when it completes.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[github-actions]

RAM / Flash usage vs. base commit 7508351 — commit 6b15c92

Using the nearest available size baseline — the PR's exact base commit has no stored baseline yet.

Target	Flash Δ	RAM Δ
MATEKF405 ⚠️	-16 B (-0.00%)	CCM: +4096 B (+14.39%) RAM: -6336 B (-5.74%)
MATEKF722 ⚠️	+136 B (+0.03%)	ITCM_RAM: +96 B (+0.77%) RAM: -2000 B (-2.25%) TCM: ±0 B (±0.00%)
MATEKF765 ⚠️	-540 B (-0.07%)	DTCM_RAM: ±0 B (±0.00%) SRAM1: -2228 B (-1.75%)
MATEKH743 ⚠️	+52 B (+0.01%)	D2_RAM: ±0 B (±0.00%) DTCM_RAM: ±0 B (±0.00%) ITCM_RAM: ±0 B (±0.00%) RAM: -2244 B (-1.55%)

See RAM/flash optimization guide for techniques to reduce usage.

[github-actions]

Test firmware build ready — commit 6b15c92

Download firmware for PR #12061

251 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.