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/LAUNCHXL-CC2650: Calling UART_read() function causes the task to get stuck

Part Number: LAUNCHXL-CC2650
Other Parts Discussed in Thread: TEST2, CC2650

Tool/software: TI-RTOS

I am developing code which I want to use to communicate throught UART. Now I have been testing and setting different parameters for the UART config, and writing the UART is no problem at all. But whenever I want to read the RX buffer with UART_read or UART_readpolling, the task gets stuck and ends somewhere waiting forever. When I declare a timeout in the readTimeout uartParam, it does seem to continue running the code when it has reached its timeout, but the data has not been read.

I have been searching for quite a while and could not find an answer to this problem. There was one person with a similar problem who posted on this forum, but solved it by running the example uart_echo code from TI-RTOS. Sad to say, this example gives the same results as my own written code which I based on the uart example.

These are my parameters:

void qbInitUART()
{
    UART_Params uartParams;
    //const char echoPrompt[] = "\fInitializing UART:\r\n";

    /* Create a UART with data processing off. */
    UART_Params_init(&uartParams);
    uartParams.readTimeout = 100;
    uartParams.writeTimeout = 100;
    uartParams.writeDataMode = UART_DATA_BINARY;
    uartParams.readDataMode = UART_DATA_BINARY;
    uartParams.readReturnMode = UART_RETURN_FULL;
    uartParams.readEcho = UART_ECHO_OFF;
    uartParams.baudRate = 19230;
    uart = UART_open(Board_UART0, &uartParams);

    if (uart == NULL) {
        System_abort("Error opening the UART");
    }

    //UART_write(uart, echoPrompt, sizeof(echoPrompt));
}
static void UART_taskFxn(UArg arg0, UArg arg1)
{
    // Initialize the task parameters
    UART_task_Init();

    for (;;) {
     
//Random chars for testing static uint8_t test[] = "1"; static uint8_t test2[] = "0"; UART_write(uart, &test, sizeof(test)); UART_read(uart, &test2, sizeof(test2)); memcpy(test, test2, sizeof(test2)); Task_sleep(sleepTickCount); } }

The IOID pins 2 and 3 are connected to eachother, and the board files also seem to correctly initialize these pins as UART pins. I use the test2 variable to detect whether the data is correctly read from the UART_write() of the variable test. If it results in continuously writing the ASCII "1", then it means that the reading succeeded.

The UART_init(); is called in the main.c file and the parameters is called when I initialize the task. I have been looking at this for quite a while, and am using a logic analyzer to verfiy the sent data, but it always resulted in "0" instead of continuously "1". I can't figure out what I am doing wrong right now.

  • Just to be clear....have you gotten UART Echo in the SDK to work out of the box unchanged on the LP?

    What does the application do? Is it just bad data or does it go into the weeds? Did you check stack sizes in ROV to make sure nothing was blown?

    Also what version of SDK are you using?
  • Hey ToddMullanix, thanks for answering!

    I loaded the echo example from the resource explorer, and debugged it directly on multiple launchpads with the same result. The data sent by the application seems to be normal and correct. But when it tries to read, it just freezes somewhere, I haven't found out exactly where since it is somewhere in the disassembly code.

    About the version, I had some doubts about this since I installed multiple versions of BLE and TI-RTOS in CCS. The echo example I used is imported from version 2.21.00.06 from TI RTOS for CC13XX and CC26CC. But isnt it supposed to be configured correctly in the project properties already?

    It is usually stuck here in the disassembly, no idea if this helps:

    10000486:   4770                bx         lr

  • Hi Garfie,

    "I loaded the echo example from the resource explorer, and debugged it directly on multiple launchpads with the same result. The data sent by the application seems to be normal and correct. But when it tries to read, it just freezes somewhere, I haven't found out exactly where since it is somewhere in the disassembly code."

    So you run the UART  echo example and open a UART terminal (ie. PuTTY) with the correct COM Port and baud. You see the prompt: "Echoing characters:"; but you're unable to type anything into the terminal?

    If the RX jumper is missing, you will see the "Echoing characters:" prompt but will be unable to type into the terminal.

    If the TX jumper is missing, you will not see a prompt and will not be able to type into the terminal.

    Is your UART connection in your application using the LP DIO2 and DIO3? If so, have you tried removing the RX and TX jumpers?

    I imported the uartecho example for CC2650 and it worked for me. Anytime I paused the application, its @0x10000486; this seems normal.

    Derrick

  • Alright teeny tiny update, I have been kind of stupid while programming. Like you said, I had to type to actually echo anything out. So there doesn't seem to be a problem with UART anymore with this knowledge.

    However, this means that the UART always stops my entire task whenever I want to read something. Usually I can read a RX buffer to gather any messages sent via UART. Does this mean I have to make one myself (like making another task to implement a buffer), or is there a function in UART.h I'm not seeing right now? Because this is pretty troublesome when I need to be able to respond to those messages within a milliseconds window while holding the bluetooth connection.

  • Garfie,

    From what I can tell, you're using the UART in UART_MODE_BLOCKING. If you don't want the UART_read() to stop your task execution, you can use UART_MODE_CALLBACK.

    Here's an exert from the UART API documenation. You can find the full documentation in /docs/tidrivers/tidriversAPIs.html in your product installation.

    "UART_MODE_CALLBACK is non-blocking and UART_read() and UART_write() will return while data is being sent in the context of a hardware interrupt. When the read or write finishes, the UART driver will call the user's callback function. In some cases, the UART data transfer may have been canceled, or a newline may have been received, so the number of bytes sent/received are passed to the callback function. Your implementation of the callback function can use this information as needed. Since the user's callback may be called in the context of an ISR, the callback function must not make any RTOS blocking calls. The buffer passed to UART_write() in UART_MODE_CALLBACK is not copied. The buffer must remain coherent until all the characters have been sent (ie until the tx callback has been called with a byte count equal to that passed to UART_write())."

    Derrick
  • Hey Derrick,

    Hmm, I think I will have to try that tomorrow as well then since I left it at the office for now. Thanks for the answers anyway, I really appreciate that! I was worried I might get dunked in this forum for lacking knowledge of programming.