arch/arm/stm32: serial setformat writes CR1 parity/word-length bits with UE=1 in several drivers

Open
  • Is something wrong?
#20,969 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@ashishgit4 is already working on this.

Since Oct 25, 2026.

  • #20993 by @Sarthak-Pandey — closed without merging

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
embedded-iot

Research direction

Read the listed STM32 driver paths and compare their setformat implementations with the fix in #20914 and the H7, F7, and G4 patterns. Check the relevant reference manuals to confirm which peripherals require UE cleared before changing CR1; the issue marks these reports as static review only. Done means confirmed affected drivers handle the register update correctly, with hardware readback where available.

Written by the indexing model from the issue text.

Description

Summary

On USART v2 and later peripherals, PCE and M0/M1 in CR1 can only be written while UE=0 (RM0394 for L4). Several STM32 serial drivers handle TCSETS by calling setformat(), which writes CR1 with UE=1. The write is silently ignored, so tcsetattr() returns 0 but the parity and word length do not change.

Verified on hardware (STM32L4)

NUCLEO-L432KC: stm32l4serial_setformat() wrote CR1 = 0x142d and read back 0x2d. PCE and M0 did not stick, so 8E1 requests stayed 8N1. This was fixed in #20914 (UE saved, cleared, registers written, UE restored, in a critical section), following the pattern already used by the H7, F7 and G4 drivers.

Suspected, from static review only (not reproduced, not checked against each RM)

The same pattern, with no UE handling around the CR1 write in setformat, appears in:

  • arch/arm/src/stm32wb
  • arch/arm/src/stm32wl5
  • arch/arm/src/stm32n6
  • arch/arm/src/common/stm32/stm32_serial_m33_v3.c (L5/U5/H5)
  • arch/arm/src/common/stm32/stm32_serial_m0_v3.c (F0, e.g. F030, which selects STM32_HAVE_IP_USART_V3)
  • the F3 branch (F30XX/F33XX/F37XX) of stm32_serial_m3m4_v1v2v3v4.c, where up_set_format only clears UE|TE|RE under #ifdef STM32G4XXX

F1/F2/F4 (USART v1) were not checked against their RMs.

Offer

I have no boards for most of these, so I cannot test fixes. If the maintainers want PRs for these drivers, I can send them following the #20914 pattern. Anyone with the hardware is welcome to confirm by reading CR1 back after tcsetattr(8E1).

Dominant language
C
Stars
4.1k
Forks
1.8k
Avg merge
1d 3h
Merged PRs (30d)
833

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/nuttx

All issues in apache/nuttx

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.