• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 503 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/CC2650: UART_read with callback eventually crashes. And I think I tried everything.

Giovanni Peroni
Intellectual 695 points
Part Number: CC2650

Tool/software: TI-RTOS

I'm using tirtos_cc13xx_cc26xx_2_21_01_08.

I'm running UART_read and UART_write in parallel. The initial naive implementation was having the callback function set via uartParams.readCallback calling UART_read again. From what I read online that is ok, but I see it crashing after an hour or so, the callback function is never called even though there is UART activity on the bus.

I've then moved on to an implementation where the callback function releases a semaphore and the main thread calls _read again when that happens. This was worse than before, but when I add another function checking for the RXE bit to restart the read process I got it the most stable it has been.

    if(Semaphore_getCount(uart_read_sem) != 0)
    {
        Semaphore_pend(uart_read_sem, -1);
        UART_read(uartHandle, &uart_rx_buf[uart_next_rx_bufpos], uart_next_rx_bytes);
    }
    else if(!(HWREG(UART0_BASE + UART_O_CTL) & UART_CTL_RXE))
    {
       // Semaphore_pend(uart_read_sem, -1);
        UART_read(uartHandle, &uart_rx_buf[uart_next_rx_bufpos], uart_next_rx_bytes);
    //    while(1);
    }

But it still crashes. Please see the registers dump attached.

What the heck am I supposed to do here?

Thank you!

  • 0
    TI__Genius 15590 points
    Hi Giovanni,

    From looking at your registers, it appears you are getting UART Overrun Errors and UART Framing Errors.

    Are you using the same RTOS task for the read and blocking write operation? Could it be that the task is blocked performing the write and your task can't service the read callback, thus a RX FIFO overflow occurs?

    I would also recommend checking out the uartecho example in the SDK and reading up on the UART driver in UART.h, specifically about the modes of operation and to ensure that you are initializing/handling reads and writes properly.

    Thanks,
    Alexis
  • 0 in reply to Alexis Crandall20
    Intellectual 695 points
    Nice answer, thank you Alexis.

    Yes, I'm calling _read from the same task. Yes, that's a good reason for the overrun/framing errors, but shouldn't the driver handle errors one way or the other? HAL for example has a _error callback, does the driver not do anything when errors occur during reception? Errors are going to occur, even moving it to a different task, so there should be an error handling mechanism, I believe we both agree.

    I've read up on UART.h but didn't find anything particular.

    The idea here is to add some kind of error handling mechanism, would calling UART_read() on overrun/framing errors work for that? Or maybe using a timeout so that the read callback function is called and the code continues?

    Thanks again,
    Giovanni
  • 0 in reply to Giovanni Peroni
    TI__Genius 15590 points
    HI Giovanni,

    Are you using the UART driver in callback mode rather than blocking mode? If so, maybe consider switching because blocking mode seems to do exactly what you're wanting to implement.
    It uses a semaphore so that the UART_write() or UART_read() call will block until all data is sent or received, or the write timeout or read timeout expires, whichever happens first.


    Thanks,
    Alexis