Skip to content

Fix rare NRF52 serial TX lockup #8910

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

Merged
merged 1 commit into from
Dec 5, 2018
Merged

Conversation

c1728p9
Copy link
Contributor

@c1728p9 c1728p9 commented Nov 30, 2018

Description

When using UARTSerial to send serial data the uart NRF52 UART driver follows the sequence below:

<-TX done ISR runs and sets a software interrupt to pending
<-Software interrupt fires:
    -disables TX done interrupt
    -calls UARTSerial TX handler which sends bytes until the uart
     buffer is filled (writeable returns false). Sending a byte
     re-enables the TX done interrupt continuing the cycle

Due to this sequence, if the UARTSerial TX handler does not send a byte then the transmit state machine mentioned above will get stuck with the TX done interrupt disabled. The events causing this failure:

<-TX done ISR runs and sets a software interrupt to pending
<-Software interrupt fires:
    -disables TX done interrupt
    -calls UARTSerial TX handler:
        -checks writeable which is true and sends a byte
            <- interrupted by a higher priority interrrupt
            <- TX done ISR runs, setting software interrupt to
               pending again
        -checks writeable which is true and sends a second byte
    -Software interrupt finishes
<-Software interrupt fires:
    -disables TX done interrupt
    -calls UARTSerial TX handler:
        -checks writeable which is false and DOES NOT SEND A BYTE
    -Software interrupt finishes, the TX interrupt is still disabled
*-Byte gets sent but TX done ISR does not fire

This patch prevents the TX lockup by removing the code in the software interrupt which disables the TX done interrupt. Disabling the TX done interrupt at this point is not necessary so this code is safe to remove.

Pull request type

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

When using UARTSerial sending data over the uart follows the sequence
below:
<-TX done ISR runs and sets a software interrupt to pending
<-Software interrupt fires:
    -disables TX done interrupt
    -calls UARTSerial TX handler which sends bytes until the uart
     buffer filled (writeable returns false). Sending a byte
     re-enables the TX done interrupt continuing the cycle

Due to this sequence, if the UARTSerial TX handler does not send a byte
then the transmit state machine mentioned above will get stuck with
the TX done interrupt disabled. The events causing this failure:
<-TX done ISR runs and sets a software interrupt to pending
<-Software interrupt fires:
    -disables TX done interrupt
    -calls UARTSerial TX handler:
        -checks writeable which is true and sends a byte
            <- interrupted by a higher priority interrrupt
            <- TX done ISR runs, setting software interrupt to
               pending again
        -checks writeable which is true and sends a second byte
    -Software interrupt finishes
<-Software interrupt fires:
    -disables TX done interrupt
    -calls UARTSerial TX handler:
        -checks writeable which is false and DOES NOT SEND A BYTE
    -Software interrupt finishes, the TX interrupt is still disabled
*-Byte gets sent but TX done ISR does not fire

This patch prevents the TX lockup by removing the code in the
software interrupt which disables the TX done interrupt. Disabling the
TX done interrupt at this point is not necessary so this code is safe
to remove.
@0xc0170
Copy link
Contributor

0xc0170 commented Dec 5, 2018

CI started

@mbed-ci
Copy link

mbed-ci commented Dec 5, 2018

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts
Build logs

@0xc0170 0xc0170 merged commit 1c201b4 into ARMmbed:master Dec 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants