[BUG] arch/arm/stm32n6: USART hardware format and baud rate changes silently ignored at runtime (UE not disabled)

Chiusa
  • Qualcosa non va?
#21,377 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #21380 di @Swatantra-66 — integrata

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
c
Ambito
embedded-iot, operating-systems

Direzione di ricerca

The change belongs in stm32serial_setformat() in arch/arm/src/stm32n6/stm32_serial.c, which writes BRR, CR1 and CR2 while the USART may still be enabled. Compare it with the STM32L4 implementation the issue cites, which shows the expected UE save, clear and restore pattern inside enter_critical_section()/leave_critical_section(). Done means UE is cleared before the register writes, its previous state is restored afterwards, and a runtime tcsetattr() change takes effect on hardware. A linked pull request (#21380) already exists, so review it before starting.

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

Descrizione

Arch: arm Area: Drivers OS: Linux Type: Bug
Description

In arch/arm/src/stm32n6/stm32_serial.c, stm32serial_setformat() updates the baud rate register (BRR), CR2 STOP bits, and the PCE, PS, M0, and M1 bits of CR1 without first clearing the USART enable bit (UE = 0).

Per the STMicroelectronics STM32N6 Reference Manual (RM0486), the baud rate register and line control bits in CR1 and CR2 are write-protected while the USART is enabled (UE = 1). Consequently, any runtime tcsetattr() call attempting to change baud rate, parity, word length, or stop bits returns 0 (Success), but the hardware USART registers silently remain unchanged.

Additionally, stm32serial_setformat() lacks critical section protection (enter_critical_section() / leave_critical_section()), leaving register modifications vulnerable to concurrent interrupts.

Steps to Reproduce

  1. Configure and boot a board using the STM32N6 USART driver (e.g. nucleo-n657x0-q:nsh or stm32n6570-dk:nsh).
  2. From user space or NSH, open the serial port and attempt to reconfigure baud rate or framing at runtime via tcsetattr(fd, TCSANOW, &termios).
  3. Notice that tcsetattr() returns success (OK), but the hardware continues transmitting/receiving with the initial boot baud rate and framing.

Expected Behavior

stm32serial_setformat() should:

  1. Enter a critical section (enter_critical_section()).
  2. Read CR1, preserve the current USART_CR1_UE state, and clear USART_CR1_UE.
  3. Apply the updated BRR, CR1, CR2, and CR3 settings while UE = 0.
  4. Restore USART_CR1_UE to its previous state.
  5. Exit the critical section (leave_critical_section()).

This aligns STM32N6 with the approved implementations in STM32L4 (commit 47180bf5ea), STM32WB (PR #21334), STM32WL5 (PR #21336), STM32H7, and STM32F7.

Additional Context

I have verified the root cause and have a tested patch ready to submit

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Ubuntu 22.04 / Linux

NuttX Version

master

Issue Architecture

[Arch: arm]

Issue Area

[Area: Drivers]

Host information

No response

Verification
  • I have verified before submitting the report.
Lingua principale
C
Stelle
4.1k
Fork
1.7k
Merge medio
1g 3h
PR unite (30g)
872

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.