daniel-p-carvalho opened a new issue, #20969: URL: https://github.com/apache/nuttx/issues/20969
## 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)`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
