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.

CC2650, UART: Parallel reading and writing

Other Parts Discussed in Thread: CC2650, CC2640

Hi everybody

My application running on a SmartRF06EB / CC2650 is connected to a PC and I would like to use the serial port to communicate with the PC. Reading and writing is working "more or less" now, but would like to have it more reliable. How am I supposed to use the UART driver to do parallel read and write? For me this is not clear from this description:
C:/ti/tirtos_simplelink_2_13_00_06/docs/doxygen/html/_u_a_r_t_c_c26_x_x_8h.html

I use UART_read in callback mode and UART_write in blocking mode. After the initialization I do a single UART_read. I the read callback, after processing the data, I call another UART_read. Reading data only works perfectly with that system.

But after a single UART_write, I do not get any more read callbacks. I was able to fix this using a timer that performs a new UART_read every 100ms but that is definitely not the way to go. Do you have any advice?

  • Hello Fabien,

    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?

    Best wishes
  • Yes, I use the same task for reading and writing. To check for errors, I have the following code block after any read and write:

    UART_Status uartStatus = ((UARTCC26XX_Object*)(uartHandle->object))->status;
        if (uartStatus != UART_OK)
        {
            PIN_setOutputValue(ledPinHandle, Board_LED3, 1);
            PIN_setOutputValue(ledPinHandle, Board_LED3, 0);
            return false;
        }

    The program never enters the if-block (tested using breakpoints and logic analyzer) except if I unplug the USB cable. My read commands all read only one byte per interrupt:

    UART_read(uartHandle, uartRxBuf, 1);

    Would you recomend using two tasks? One to send and one to receive.

  • I have exactly the same problem. I can read all I want, it works. As soon as I send anything down to the second microcontroller, from that side everything goes well. The message is received, proecessed and the response is sent back to my CC2640. But the read callback is never called again...

    The second microcontroller sends messages to the CC2640 all the time, so it is quite sure that during UART_write() a message is being sent from there to the CC2640...

    Any ideas? Semaphore problem?
  • One task is just fine.

    Just curious, have you used an logic analyzer to see if you're still getting incoming data after your sent that one byte? I just want to make sure that the UART peripheral is still sending data.

    Tom

  • I changed to program such that it uses separate tasks for sending and receiving. It had no influence. The problem remained.
  • One task is just fine.

    Just curious, have you used an logic analyzer to see if you're still getting incoming data after your sent that one byte? I just want to make sure that the UART peripheral is still sending data.

  • You might be hitting a known bug in the UART driver, which can release power constraints at the wrong time if you combine UART TX and RX. That was fixed in TI-RTOS 2.14.01.20 for CC26xx.
  • Hello,
    I am also trying for parallel read and write. My program works when i disable the Power Saver predefined symbol. will i need to change the RTOS, currently i am using 2.13.0.06.
    Thanks
    Gourang
  • Hi Gourang,
    We generally discourage posting a new question to an old closed thread because the person who answered before may no longer be available, and also it will allow whomever is currently assigned to monitor the forum to respond to you more quickly. For these reasons, I suggest you start a new thread with your question and reference this thread.

    Thank you
  • Hello Gourang,

    You will need to use the newer RTOS driver as Robert Cowsill mentions.

    Best wishes