Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#20,969 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Sarthak-Pandey ci sta già lavorando.

Dal 25/10/2026.

  • #20993 di @Sarthak-Pandey — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c
Ambito
embedded-iot

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).

Lingua principale
C
Stelle
4.1k
Fork
1.7k
Merge medio
1g 9h
PR unite (30g)
533

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/nuttx

Tutte le issue di apache/nuttx

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.