Closed bisqwit closed 7 years ago
cc @bcostm @adustm @LMESTM @jeromecoutant
@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. In case of L0 HAL_UART_GET_IT_SOURCE Checks whether the specified UART interrupt source is enabled HAL_UART_GET_IT Checks whether the specified UART interrupt has occurred or not so it seems that we may not be using the proper MACRO
Before proposing a fix, I'd like to reproduce your issue and make sure I will solve it. May you please provide come sample code and describe the use case where you tested so that I can easily reproduce the issue ?
@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 :
$ git diff targets/TARGET_STM/TARGET_STM32L0/serial_device.c
--- a/targets/TARGET_STM/TARGET_STM32L0/serial_device.c
+++ b/targets/TARGET_STM/TARGET_STM32L0/serial_device.c
@@ -214,7 +214,7 @@ static void uart_irq(int id)
}
}
if (__HAL_UART_GET_FLAG(huart, UART_FLAG_ORE) != RESET) {
- if (__HAL_UART_GET_IT_SOURCE(huart, UART_IT_ORE) != RESET) {
+ if (__HAL_UART_GET_IT(huart, UART_IT_ORE) != RESET) {
__HAL_UART_CLEAR_FLAG(huart, UART_CLEAR_OREF);
}
}
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
ST_TO_BE_CLOSED
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?