• Resolved

LAUNCHXL-CC1310: UART_read functionality issue

Part Number: LAUNCHXL-CC1310

Hi Team,

I am observing a strange behaviour while executing the UART firmware.

 * CommandRadio.h
 * This is header file
 *  Created on: Aug 25, 2016
 *      Author: vikram



/* XDCtools Header files */
#include <xdc/std.h>
#include <xdc/runtime/System.h>
#include <xdc/runtime/Error.h>
#include <xdc/cfg/global.h>

/* BIOS Header files */
#include <ti/sysbios/BIOS.h>
#include <ti/sysbios/knl/Swi.h>
#include <ti/sysbios/knl/Task.h>
#include <ti/sysbios/knl/Clock.h>
#include <ti/sysbios/knl/Mailbox.h>
#include <ti/sysbios/knl/Event.h>

/* TI-RTOS Header files */
#include <ti/drivers/PIN.h>
#include <ti/drivers/UART.h>

/* Board Header files */
#include "Board.h"

/*Event Defines */
#define Event_Data_Rx   Event_Id_00
#define Event_Button	Event_Id_01

typedef struct MsgObj {
    Int	id;             	/* writer task id */
    String	buf;            /* message value */
} MsgObj, *Msg;

/* UART params */
UART_Handle uart;

typedef void(*UartRead_Callback)(uint8_t *ch);

/*Function Prototypes */
void uartSendTask(UArg arg0,UArg arg1);			/* This is the Task that handles the write to terminal call */
void processMsg(MsgObj *message);				/* This is called by reciept of a mailbox message */
void writeToTerminal(String txtString);			/* This is the function called to send a mesage to back channel UART */

void UartRead_registerCallback(UartRead_Callback callback);

#endif /* COMMANDRADIO_H_ */

 * CommandRadioUart.c
 * This is source file
 *  Created on: Aug 25, 2016
 *      Author: vikram
#include "CommandRadio.h"

uint8_t *command;
static char uart_rxBuffer;//Read one byte at a time

/***** Variable declarations *****/
static UartRead_Callback Callback;

/* Prototype */
static void uartReceiveFinished(UART_Handle handle, void *uart_rxBuffer, size_t count);

/* This task is declared in CommandRadio.cfg
 * It transmits text over the UART backchannel USB  */
void uartSendTask(UArg arg0,UArg arg1){
	MsgObj dataRx;

    UART_Params uartParams;

    /*initializing the UART parameters*/
    uartParams.writeDataMode = UART_DATA_TEXT;
    uartParams.readMode = UART_MODE_CALLBACK;
    uartParams.readDataMode = UART_DATA_TEXT;
    uartParams.readReturnMode = UART_RETURN_FULL;
    uartParams.readEcho = UART_ECHO_OFF;
    uartParams.readCallback = uartReceiveFinished;
    uartParams.baudRate = 115200;
    uart = UART_open(Board_UART0, &uartParams);
    if (uart == NULL) {System_abort("Error opening the UART");}
    // Clear the uart_rxbuffer
    int rxBytes = UART_read(uart, &uart_rxBuffer, 1);

/* The task suspends waiting on reciept of mailbox message.*/
	    UART_read(uart, &uart_rxBuffer, 1);
		Mailbox_pend(rxDataMailbox, &dataRx, BIOS_WAIT_FOREVER);

void UartRead_registerCallback(UartRead_Callback callback) {
	Callback = callback;

/* This function writes the Text messge to the UART, The UART write can be formated here */
void processMsg(MsgObj *message){
	UART_write(uart, message->buf, strlen(message->buf));
/* this function can be called to write to the UART */
void writeToTerminal(String txtString){
	MsgObj writeData;
		writeData.id = Event_Data_Rx;
		writeData.buf = txtString;

static void uartReceiveFinished(UART_Handle handle, void *uart_rxBuffer, size_t count)
	command = (uint8_t*)uart_rxBuffer;

If you see the firmware above you will recognise that I am trying to read something from the terminal window and send to the other device over the radio.

The problem occurs that every time I do a power on reset to the CC1310 Launchpad board  (meaning trying to power up the board by plugging in the USB cable to the PC system) by default, the execution calls the uart callback function i.e. "uartReceiveFinished" even though I have not punched any key on the keyboard to interact with the terminal window.

I don't observe this behaviour if I press the reset button on the Launchpad nor I observe this behaviour if I run the firmware in debug mode.

I would like to know if there is any conditions set in the UART driver that is specific for the power on reset using the USB port that triggers the UART call back function.

As per my knowledge resetting the board using the reset button or by plugging and unplugging the usb cable should show the same behaviour.

Please correct me if I am wrong.

Thank you in advance.


  • Hi Team,

    I am still awaiting for someone to respond this query.
    To make sure that this is related to CC1310 Launchpad I have the same firmware written for the CC1310DK board and I don't find this issue on those boards.
    It's only when the firmware is burnt and executed on the CC1310 launch pad I get this behaviour.
    Please need to get to the root cause as I want to apply a workaround but I get different behaviour if I do reset button press or the Power on reset.

  • In reply to Vikram Trivedi:

    Hi Team still waiting for someone to get back on this issue as I am not able to use the launchpad feature as needed.
    Thank you
  • In reply to Vikram Trivedi:

    Hi Team,

    Its been over couple of weeks is anybody able to let me know the solution.

    If it's not possible I will have to switch to the development board and modify the firmware.

    Waiting for a response.


  • In reply to Vikram Trivedi:


    I can reproduce this behavior. It seems that the debugger chip pulls the UART RX pin down for about 30 ms after start.

    The UART peripheral on the CC1310 interprets this as a message break and will abort the current RX operation.

    As a work-around, you could

    • not use the UART/USB interface of the launchpad, but open the RX/TX jumpers and connect these pins to an external USB/UART dongle
    • or add an initial delay of 25 ms to your application before the first UART read.
    • or add an additional check to your callback as shown below.
    static void uartReceiveFinished(UART_Handle handle, void *uart_rxBuffer, size_t count)
        if (((UARTCC26XX_Object*)(handle->object))->status == UART_BRAKE_ERROR)
            // Ignore the callback in that case. The UART found the RX line to be
            // held low and triggers a break error.
        /* Normal case. Read data. */

    I will create a ticket for the TM4 debugger firmware on the launchpad, but honestly, I don't know if this will ever be addressed.

    Best regards


  • In reply to Richard W.:

    Thank you Richard.

    Appreciate your response. I will try with the third option and get back to you.


  • In reply to Richard W.:

    Hi Richard,

    I tried the option 2 and 3.

    The third option does not work but providing an additional delay just at the start of first read call.

    But your solution does works.

    Thank you