-
Notifications
You must be signed in to change notification settings - Fork 3k
STM32L0 UART IRQ infinitely retriggered #3452
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
Comments
@bisqwit thanks for reporting the issue and sorry for not coming back to you earlier. After a quick check, I noticed that there is a misalignment between some of MACROs definition of __HAL_UART_GET_IT_SOURCE and __HAL_UART_GET_IT. Before proposing a fix, I'd like to reproduce your issue and make sure I will solve it. |
@bisqwit I could actually build a simple example where I think that I can reproduce the same issue as you were describing. I unblocked the situation by changing :
Would be great if you could confirm it helps on your side - I will anyway post the patch accordingly. |
Fix pushed for review and test : #4707 |
#4707 has been merged and should fix the issue. Please close or share updates if any issue. |
I am having trouble where uart2_irq gets triggered, but never acknowledged, causing the IRQ being immediately triggered again when it exits, with user code never getting chance to progress.
I single-step the IRQ handler, and I see it tests and sees that
UART_FLAG_ORE
is set. Then it tests whetherUART_IT_ORE
is set, and it’s not, so it never clears the ORE condition. And the IRQ gets never acknowledged, and it therefore gets triggered again, infinitely.I made a comparison on how
uart_irq()
is written in all the different STM32 targets, and I see they are quite different on each CPU. Should they be? Should it perchance be testingUSART_IT_ERR
instead ofUART_IT_ORE
, on L0, like it is doing on F4, and like it is actually doing inserial_irq_handler_asynch()
on L0?The text was updated successfully, but these errors were encountered: