Description
Description of defect
On some targets (at least STM32L0, STM32G0) with interrupts shared between multiple UART peripherals, it is not possible to use the shared UARTs at the same time. When the second of the shared UARTs calls serial_irq_set()
, the vector to the first UART's IRQ handler is broken.
I believe this problem was handled for STM32F0 by combining the handler for each peripheral into one (uart3_8_irq
) and attaching it regardless of whether serial_irq_set()
is running for UART3 or UART8. Seems like the same thing should have been done for STM32L0 and STM32G0.
If there was a documented user-land workaround for this issue, I wasn't able to find it. Thanks!
Target(s) affected by this defect ?
STM32L0, STM32G0
Toolchain(s) (name and version) displaying this defect ?
n/a but recent GCC_ARM
What version of Mbed-os are you using (tag or sha) ?
Issue present in master
as of this writing (1443257)
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
Discovered while working on a PlatformIO project with the mbed
framework (Core 5.2.4)
How is this defect reproduced ?
Make a project with 2 BufferedSerial objects corresponding to 2 shared UARTs.
For example, this issue was discovered while trying to use USART4 and USART5 on STM32L071.
Suppose you instantiate USART4 first and USART5 second.
The USART5 handler takes over the USART4_5_IRQn.
If data is sent to USART4, the application hangs since the RXNE flag is never cleared by the USART5 handler.