• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1338 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/msp432p401r: Detecting UART overrun?

Marc Singer98
Prodigy 240 points

Part Number: msp432p401r

Tool/software: TI-RTOS

Is there hook in the TI RTOS UART driver to detect overruns?  At this point, I just trying to see whether or not overruns are the root cause of our communications failures.

Like other posters, we are attempting to communicate with a device that has a fixed baudrate of about 1Mbaud.

  • 0
    TI__Guru 73181 points
    Marc,
    I am not aware of a direct API or mechanism to detect overruns. You can use the Runtime Object View to manage/watch for stack overruns. In your specific application, what is the ring-buffer size and are you using the blocking or non-blocking implementation?

    Regards,
    Chris
  • 0 in reply to Chris Sterzik
    Prodigy 240 points

    OK.  I'll check out the Runtime Object View.  It's generally helpful to have programmatic access to this information since it may occur during program operation.

    I don't expect to overrun the ring buffer.  I can set it arbitrarily large.  As for blocking or non-blocking, I'm not sure.  I'm using the UART_read call.

  • 0 in reply to Chris Sterzik
    Prodigy 240 points
    To be clear, I am not expecting a stack overflow. I really want to know when the UART sees an overrun. That is, when the UART receives a character when the last character has not been removed from the receive register. Are you telling me that the Runtime Object Viewer is the way to do this?
  • 0 in reply to Marc Singer98
    TI__Guru 73181 points
    Marc,
    No, the ROV will not provide visibility into the peripheral. Specifically, the eUSCI peripheral provides an overrun status in the status register. It is located in the eUSCI_Ax Status Register, www.ti.com/.../slau356h.pdf .

    The UART driver checks for errors in the hwi (UARTMSP432_hwiIntFxn), and in the hardware attributes you can specify a callback, UARTMSP432_ErrorCallback.

    /*! Application error function to be called on receive errors */
    UARTMSP432_ErrorCallback errorFxn;
    } UARTMSP432_HWAttrsV1;

    /*!
    * @brief The definition of an optional callback function used by the UART
    * driver to notify the application when a receive error (FIFO overrun,
    * parity error, etc) occurs.
    *
    * @param UART_Handle UART_Handle
    *
    * @param error The current value of the receive
    * status register. Please refer to the
    * device data sheet to interpret this
    * value.
    */
    typedef void (*UARTMSP432_ErrorCallback) (UART_Handle handle, uint32_t error);

    Chris
  • 0 in reply to Chris Sterzik
    Prodigy 240 points

    Ah.  Now I see this at the end of the config structure.

    I found that the watchpoints in the ROV wouldn't detect the overrun condition in the status register.  Setting a breakpoint in the driver code did. It seems as if the MSP432 isn't fast enough to receive back-to-back characters at 921600 baud.  My test program is a small piece of code that reads from the UART, one byte at a time, and toggles an IO line after receiving each byte.  With a logic analyzer, I can see a 13 byte message being transmitted to the MSP432 and between 9 and 11 of those bytes are identified with the toggling IO line.  I can also see from the breakpoint that there is an overrun by the UART.  This is a little surprising for a 48MHz MCU, though I have not attempted to characterize the driver code to measure the length of the code path.

    If there is a more efficient method for receiving bytes from the UART, we'd be happy for the pointer.

    Cheers

**Attention** This is a public forum