Fix serial IRQ handling #10774

fkjagodzinski · 2019-06-06T10:29:48Z

Description

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

Release Notes

jeromecoutant · 2019-06-06T10:55:52Z

@ARMmbed/team-st-mcd

ciarmcom · 2019-06-06T11:00:41Z

@fkjagodzinski, thank you for your changes.
@MarceloSalazar @maclobdell @ARMmbed/mbed-os-maintainers please review.

LMESTM

Looks good to me - thanks.
should be applied to all STM32 targets in a similar way (the same MACROs should be available)

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

jeromecoutant · 2019-06-13T15:03:55Z

@fkjagodzinski
I could see you applied patch to STM32 F0/F3/F7/L0/L4/H7/WB
This is good,
But I am afraid F1/F2/F4/L1 are missing... :-(
Thx

fkjagodzinski · 2019-06-17T13:14:46Z

@jeromecoutant I think I've covered all the affected ST targets.

I provided patches for ST targets that have an if statement like this one

mbed-os/targets/TARGET_STM/TARGET_STM32F7/serial_device.c

Line 56 in 9974899

if (__HAL_UART_GET_IT(huart, UART_IT_TXE) != RESET) {

Checking __HAL_UART_GET_IT(huart, UART_IT_TXE) is not enough; additional __HAL_UART_GET_IT_SOURCE(huart, UART_IT_TXE) helps here.

F1, F2, F4 and L1 all already use __HAL_UART_GET_IT_SOURCE(), which is the only check-uart-irq macro they currently provide.

mbed-os/targets/TARGET_STM/TARGET_STM32F1/serial_device.c

Line 57 in 9974899

if (__HAL_UART_GET_IT_SOURCE(huart, UART_IT_TXE) != RESET) {

Of course I might have missed something. I've just checked NUCLEO_F207ZG, NUCLEO_F429ZI with the test code from #10773 and couldn't reproduce this issue.

adbridge · 2019-06-18T17:21:31Z

@jeromecoutant could you re-review please ?

LMESTM

Just one question left to be answered

LMESTM · 2019-06-18T08:27:30Z

targets/TARGET_STM/TARGET_STM32F0/serial_device.c

@@ -62,12 +62,12 @@ static void uart_irq(UARTName uart_name)
        UART_HandleTypeDef *huart = &uart_handlers[id];
        if (serial_irq_ids[id] != 0) {
            if (__HAL_UART_GET_FLAG(huart, UART_FLAG_TXE) != RESET) {
-                if (__HAL_UART_GET_IT(huart, UART_IT_TXE) != RESET) {
+                if (__HAL_UART_GET_IT(huart, UART_IT_TXE) != RESET && __HAL_UART_GET_IT_SOURCE(huart, UART_IT_TXE)) {


Ok so in case Interrupt has been disabled but FLAG is on anyway, handler will not be called, then shouldn't we clear the flag ?

Giving it a second thought ... that should not be required. The flag could be left in current state I guess until inerrupt is activated again

Good point; I haven't thought about that. In a normal flow, these flags are cleared by the handler (provided it actually calls serial_putc() / serial_getc()):

TXE is cleared by a write to the USART_TDR register,

RXNE is cleared by a read to the USART_RDR register.

When the handler is not called, the flags will remain asserted. I can't think of any side effects of that right now. Both flags may be cleared with the use of USART_RQR though.

LMESTM · 2019-06-19T07:46:38Z

F1, F2, F4 and L1 all already use __HAL_UART_GET_IT_SOURCE(), which is the only check-uart-irq macro they currently provide.

Right indeed. On F1, F2, F4, L1 __HAL_UART_GET_IT() is actually the same as __HAL_UART_GET_IT_SOURCE() from other families. From discussions we've had in #10853 , on those families _HAL_UART_GET_IT() does the same as __HAL_UART_GET_FLAG ...

So I'm fine with this PR.
We will need a further clean-up to fully cover the bug reported in #10853

adbridge · 2019-06-20T15:24:32Z

@LMESTM could you approve on the review if you're happy now thanks.

adbridge · 2019-06-20T15:25:25Z

@kjbracey-arm could you possibly review on behalf of maintainers ?

LMESTM

for STM targets - approved

0xc0170 · 2019-06-24T12:34:10Z

I can't find this in Travis logs, it has not even started. I'll reopen this PR

0xc0170 · 2019-06-24T12:40:10Z

Travis pending, should help

0xc0170 · 2019-06-24T21:30:17Z

CI started

mbed-ci · 2019-06-25T03:24:38Z

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

jenkins-ci/mbed-os-ci_greentea-test

fkjagodzinski · 2019-06-25T07:09:22Z

All greentea tests run for NUCLEO_F746ZG-GCC_ARM ended with IOERR_SERIAL.

[1561420280.33][GLRM][INF] remote resources reset...
[1561420297.58][GLRM][ERR] Write response(request_id: f862a6b0-96da-11e9-a49f-0242ac110002) timeout!

@0xc0170, is there a daplink/st-link issue on this board?

0xc0170 · 2019-06-25T10:11:20Z

Yes, also noticed in another test but latest one was all good, restarted

0xc0170 · 2019-06-25T14:49:26Z

This is ready to go in 👍

fkjagodzinski force-pushed the fix-uart_irq branch 2 times, most recently from c2e8417 to 189b4d6 Compare June 6, 2019 10:43

ciarmcom requested review from maclobdell, MarceloSalazar and a team June 6, 2019 11:00

ciarmcom added the needs: review label Jun 6, 2019

LMESTM reviewed Jun 6, 2019

View reviewed changes

Filip Jagodzinski added 17 commits June 7, 2019 15:17

K64F: Fix serial IRQ handling

94c27aa

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

STM32F7: Fix serial IRQ handling

8438416

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

STM32F0: Fix serial IRQ handling

c387bd8

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

STM32L0: Fix serial IRQ handling

b88b94e

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

STM32F3: Fix serial IRQ handling

d6a4821

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

STM32H7: Fix serial IRQ handling

fa0cc68

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

STM32L4: Fix serial IRQ handling

53222fa

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

STM32WB: Fix serial IRQ handling

14b83e7

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

K22F: Fix serial IRQ handling

f60850a

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

K24F: Fix serial IRQ handling

01e130b

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

KW41Z: Fix serial IRQ handling

96b6cd3

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

KW24D: Fix serial IRQ handling

0b33e8f

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

KL82Z: Fix serial IRQ handling

5f95c5f

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

KL43Z: Fix serial IRQ handling

6826967

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

K66F: Fix serial IRQ handling

9efaabe

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

KL27Z: Fix serial IRQ handling

3119d69

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

K82F: Fix serial IRQ handling

8e3ca20

Check that the RX or TX interrupt is enabled before calling a registered handler with RxIrq or TxIrq arg.

fkjagodzinski force-pushed the fix-uart_irq branch from 189b4d6 to 8e3ca20 Compare June 7, 2019 14:59

fkjagodzinski marked this pull request as ready for review June 17, 2019 14:13

jeromecoutant mentioned this pull request Jun 18, 2019

[STM32L4]serial_device irq #10853

Closed

LMESTM reviewed Jun 19, 2019

View reviewed changes

LMESTM approved these changes Jun 24, 2019

View reviewed changes

0xc0170 requested a review from a team June 24, 2019 12:21

0xc0170 approved these changes Jun 24, 2019

View reviewed changes

0xc0170 closed this Jun 24, 2019

0xc0170 reopened this Jun 24, 2019

0xc0170 added needs: CI and removed needs: review labels Jun 24, 2019

0xc0170 added ready for merge and removed needs: CI labels Jun 25, 2019

0xc0170 added the release-version: 5.13.1 label Jun 25, 2019

0xc0170 merged commit b0073bb into ARMmbed:master Jun 25, 2019

0xc0170 removed the ready for merge label Jun 25, 2019

fkjagodzinski deleted the fix-uart_irq branch June 25, 2019 16:47

Fix serial IRQ handling #10774

Fix serial IRQ handling #10774

Uh oh!

Conversation

fkjagodzinski commented Jun 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Pull request type

Reviewers

Release Notes

Uh oh!

jeromecoutant commented Jun 6, 2019

Uh oh!

ciarmcom commented Jun 6, 2019

Uh oh!

LMESTM left a comment

Choose a reason for hiding this comment

Uh oh!

jeromecoutant commented Jun 13, 2019

Uh oh!

fkjagodzinski commented Jun 17, 2019

Uh oh!

adbridge commented Jun 18, 2019

Uh oh!

LMESTM left a comment

Choose a reason for hiding this comment

Uh oh!

LMESTM Jun 18, 2019

Choose a reason for hiding this comment

Uh oh!

LMESTM Jun 19, 2019

Choose a reason for hiding this comment

Uh oh!

fkjagodzinski Jun 19, 2019

Choose a reason for hiding this comment

Uh oh!

LMESTM commented Jun 19, 2019

Uh oh!

adbridge commented Jun 20, 2019

Uh oh!

adbridge commented Jun 20, 2019

Uh oh!

LMESTM left a comment

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Jun 24, 2019

Uh oh!

0xc0170 commented Jun 24, 2019

Uh oh!

0xc0170 commented Jun 24, 2019

Uh oh!

mbed-ci commented Jun 25, 2019

Test run: FAILED

Uh oh!

fkjagodzinski commented Jun 25, 2019

Uh oh!

0xc0170 commented Jun 25, 2019

Uh oh!

0xc0170 commented Jun 25, 2019

Uh oh!

Uh oh!

fkjagodzinski commented Jun 6, 2019 •

edited

Loading