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

Cerrado
  • ¿Algo no está bien?
#21,377 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #21380 de @Swatantra-66 — fusionado

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
c
Área
embedded-iot, operating-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
C
Estrellas
4.1k
Forks
1.7k
Merge medio
1 d 3 h
PR fusionados (30 d)
836

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/nuttx

Todos los issues de apache/nuttx

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.