-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No support for UARTs with shared interrupt on some STM32 targets #15211
Comments
cc @ARMmbed/team-st-mcd |
Hi I confirm there is an issue with:
Any help is welcomed |
@jeromecoutant, here is how I patched my |
Thx @amcnicoll |
I've got the commit on a local branch. Am I right in understanding that I must first be granted access to the ARMmbed organization in order to push my branch and create the PR? |
Create a fork of Mbed Os and create a branch where you can add your commits. You can create a new pull request from your forked repository to this one. |
Thanks, it's up #15221 |
Fixed via #15221 |
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 whetherserial_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.
The text was updated successfully, but these errors were encountered: