[jlpoltrack]

Was preventing 32 Channel support over SBUS. Align to F7 / H7:

https://github.com/iNavFlight/inav/blob/maintenance-10.x/src/main/drivers/serial_uart_stm32f7xx.c#L259

https://github.com/iNavFlight/inav/blob/maintenance-10.x/src/main/drivers/serial_uart_stm32h7xx.c#L305

[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]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

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

PR Summary by Qodo

Mask parity bit before F4 UART receive callbacks

🐞 Bug fix 🕐 Less than 10 minutes

AI Description

• Mask F4 UART callback data to eight bits so parity cannot alter received bytes.
• Restore SBUS frame detection for 32-channel reception, consistent with F7 and H7.

Diagram

graph TD
  A["F4 UART register"] --> B["F4 IRQ handler"] --> C["Receive callback"] --> D["SBUS parser"]

Loading

High-Level Assessment

Masking at the F4 UART callback boundary fixes the value for every callback consumer and matches F7/H7 behavior. Masking only in SBUS would leave other callback consumers exposed.

Files changed (1) +1 / -1

Bug fix (1) +1 / -1

serial_uart_stm32f4xx.cLimit F4 UART callback data to eight bits +1/-1

Limit F4 UART callback data to eight bits

• Masks the UART data register with 0xFF before invoking a receive callback, preventing bit 8 from changing byte comparisons in parity-enabled protocols. The receive-buffer path is unchanged.

src/main/drivers/serial_uart_stm32f4xx.c

[github-actions]

RAM / Flash usage vs. base commit e87050f — commit ba39efa

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

Target	Flash Δ	RAM Δ
MATEKF405	±0 B (±0.00%)	CCM: ±0 B (±0.00%) RAM: ±0 B (±0.00%)
MATEKF722	±0 B (±0.00%)	ITCM_RAM: ±0 B (±0.00%) RAM: ±0 B (±0.00%) TCM: ±0 B (±0.00%)
MATEKF765	±0 B (±0.00%)	DTCM_RAM: ±0 B (±0.00%) SRAM1: ±0 B (±0.00%)
MATEKH743	±0 B (±0.00%)	D2_RAM: ±0 B (±0.00%) DTCM_RAM: ±0 B (±0.00%) ITCM_RAM: ±0 B (±0.00%) RAM: ±0 B (±0.00%)

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

[github-actions]

Test firmware build ready — commit ba39efa

Download firmware for PR #12109

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.

[sensei-hacker]

Thanks!