• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 78 subscribers
  • Views 700 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP432P4111: UART Receive Interrupt Flag Not Getting Set On Incoming Characters

BIt_Banger
Intellectual 880 points

Part Number: MSP432P4111

I've managed to enter a mode on the UART where the receive interrupt is not getting triggered even though characters are coming in, and I can verify the physical signal is making it to the receive pin.  When I pause the emulator I look at the registers, global interrupts are enabled, the UART is enabled, as is the UART receive interrupt enable flag, but the receive interrupt flag is not getting set.

When I reset the processor the UART works fine again.

Any ideas?

Thanks.

  • 0
    TI__Expert 7365 points

    Hello,

    What does the UCAxSTATW status register show? Are there any ERROR flags set in that register? It might give some indication of what the problem might be?

    Srinivas

  • 0 in reply to Srinivas Lingam
    Intellectual 880 points

    I am getting occasional over-run errors, but shouldn't the receive interrupt still get triggered?  Or is there a situation in which the receive interrupt flag will get set, but the interrupt won't trigger?  In which case a recovery mechanism might be to monitor the interrupt flag and reset the port if it's set and it doesn't trigger an interrupt.

  • 0 in reply to BIt_Banger
    TI__Expert 7365 points

    Hello,

    The receive interrupt is triggered before the overflow occurs. If the overflow occurs, it indicates that the UCxRXBUF was not read and the interrupt was not processed? You will not get a 2nd interrupt as the 1st received word was not read/processed.

    Section 24.3.6 Automatic Error Detection of the Technical Reference Manual (www.ti.com/.../slau356) suggests the following flow to detect and handle overflow conditions:

    Srinivas

  • 0 in reply to Srinivas Lingam
    Intellectual 880 points

    This is useful information.  However, I'm finding more often than not that none of the bits of the UCASTATW register are set including the over-run flag, and the receive interrupt flag remains zero as my host application repeatedly sends it messages with no response.

  • 0 in reply to Srinivas Lingam
    Intellectual 880 points

    I've managed to verify that this behavior is repeatable by observing it a number of times on two different boards.  The receive interrupt flag ceases to get triggered, even though the status register is zero.

  • 0 in reply to BIt_Banger
    Intellectual 880 points

    Another observation is this issue is only happening on EUSCIA0, but we are also using EUSCIA1 and EUSCIA3 for other UART ports, and neither is experiencing this issue, though the drivers for the three ports are identical.

    The port recovers when the processor is reset, so a workaround may be to reset the port when the issue is identified.

  • 0 in reply to BIt_Banger
    Intellectual 880 points

    OK, I added logic to the receive interrupt such that if any of the four error flags are set (EUSCI_A_UART_OVERRUN_ERROR, EUSCI_A_UART_RECEIVE_ERROR, EUSCI_A_UART_FRAMING_ERROR, or EUSCI_A_UART_PARITY_ERROR) the receive buffer is not read.

    So far so good, I'm not seeing the lockup issue.  It's possible I was misled when I read all zeros in the status register, since one or more of those flags may have been cleared before I got the chance to look at them.

    Thanks for the tip.

  • 0 in reply to BIt_Banger
    Intellectual 880 points

    Update:  I'm still seeing the same problem, despite adding the logic above.

  • 0 in reply to BIt_Banger
    Intellectual 880 points

    OK, found the problem, a transceiver direction pin was getting set incorrectly.

**Attention** This is a public forum