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.

Compiler/CC2650: UART RX error

Part Number: CC2650

Tool/software: TI C/C++ Compiler

Hi everyone,

I would like to ask your help in the following problem:

I had connected the FT232RQ chip to the CC2650 UART. The communication works perfectly both ways (sending, receiving) when settings are correct.

BUT, when the RX pin of the microcontroller gets to logical level 0, OR the data arrives from the PC side with incorrect speed due to an incorrect consol setup, the firmware execution terminates.

The FT232RQ’s power supply provided by a 5V USB. When USB disconnected, power discontinues. Because of this, I had enabled the pull-up resistor at the RX input of the microcontroller to ensure the logical level of 1. The problem appearance got fewer this way, but still exist. The problem is not triggered by a concrete event, can appear any time and case, expect when USB not connected since the startup.

The problem can be reproduced easily, using CC2650 LaunchpadPad and UART Echo example utility.

Eg.: sending several bytes from the PC console with 9600bps at 4800bps setting. In this case, the microcontroller does not respond after PC console gets back to the correct speed of 9600bps.

In the files of UARTCC26XX.c I can see Log_print lines. I had installed the UIA and tried to enable logging feture, but nothing appear there, though tha RTOS analyser seems to be working.

Any concrete help would greatly appriciated!

CCS Version: 8.3.0.00009

UART_Echo imported from: c:\ti\tirtos_cc13xx_cc26xx_2_21_01_08\examples\TI\CC2650_LAUNCHXL\uartecho

Driver location: c:\ti\tirtos_cc13xx_cc26xx_2_21_01_08\products\tidrivers_cc13xx_cc26xx_2_21_01_01\packages\ti\drivers\uart

Compiler: TI v16.9.4.LTS

UIA: 2.30.1.02

Added lines to the uartecho.cfg

var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
var LoggerStopMode = xdc.useModule('ti.uia.loggers.LoggerStopMode');

LoggerStopMode.common$.diags_USER1 = xdc.module("xdc.runtime.Diags").ALWAYS_ON;
LoggerStopMode.common$.diags_USER2 = xdc.module("xdc.runtime.Diags").ALWAYS_ON;
LoggerStopMode.common$.diags_INFO = xdc.module("xdc.runtime.Diags").ALWAYS_ON;

Many thanks,

Laszlo

  • Hey Laszlo,

    Are you experimenting with a LAUNCHXL-CC2650 or your own CC2650 custom board?

    BR,
    Seong
  • Hi Seong,

    I use a custom panel, but the problem can be reproduced easily, using CC2650 LaunchpadPad and UART Echo example code.

    Please follow the steps below:

    1. Import the UART_Echo example project into CCS from TI Resource Explorer.
    2. Select TI v16.9.4.LTS compiler in project settings.
    3. Debug the imported project, and upload the CC2650 LaunchPad.
    4. Click the start button, and open the serial terminal.
    5. Set baud rate to 9600bps in terminal settings, and test communication.... Send some characters to the Launchpad... all OK.
    6. BUT! Select terminal to lower than 9600bps. Eg. 4800bps, 2400bps, or 1200bps.
    7. Send some character to the Launchpad from PC terminal...
    ...and UART_read(uart, &input, 1) function does not return any more.

    Many thanks,

    Laszlo
  • Laszlo,

    I understand. One requirement when using UART is that both devices operate at the same rate. The baud rate determines how fast you're sending data over the serial line and also how long the transmitter holds a serial line high/low or at what period the receiving device samples its line. This is why you're observing this behavior.

    BR,
    Seong
  • Hi Seong,

    Thanks for your reply.

    What you had written is obvious, but there are circumtenses, when wrogn speed settings can occur, without being any control of it, so unfortunatelly I have to treat this a srive bug and i need to fix it somehow.

    What i had beeen described in my last post is an way to reproduce the problem. Very same problem occur, when RX pin pulled of momentiraly (like when USB connected, disconected or any other cases, even by a signal generated from PC terminal). So, this must be treated as a serious bug, and cannot be left as it is unfortunatelly.

    I fully understand if this problem is unique enough, so lets approach the problem from an other angle: I try to fix the bug in the driver itself. I mean I had edited the UARTCC26XX.c source code related to UARTCC26XX.c file, but when trying to compile it, the compiler does not take this file into consideration, during the compiling process. I tried to import the UART driver into the project, but then, during teh compiling process, I got "redefined" errors with al the UART functions. I could spot it, that it tries to compile the driver from the drivers_cc26xxware.aem3 object. This is a binary file at this location: C:\ti\tirtos_cc13xx_cc26xx_2_21_01_08\products\tidrivers_cc13xx_cc26xx_2_21_01_01\packages\ti\drivers\lib

    So, could you help me please, how can I tell to the compiler to use UARTCC26XX.c instead of drivers_cc26xxware.aem3 ?

    Many thanks for your help,

    Laszlo
  • Laszlo,

    Before we proceed further, have you tried implementing a timeout in the readTimeout uartParam?

    Also, did configure the UART driver to operate in blocking mode or callback mode? If you didn't set this parameter, the driver defaults to blocking mode, which can cause UART_read() to stop your tasks. Instead, you can use UART_MODE_CALLBACK which is non-blocking. For more information about UART callback mode, refer to the UART API doc here.

    BR,

    Seong

  • Hey Laszlo,

    Have you made any progress on this?

    BR,
    Seong
  • Hi Seong,

    Yes! I seem to have managed to solve the problem. I copied and renamed the UARTCC2650_readCancel(UART2_Handle handle) to UARTCC2650_resetReceiver(UART2_Handle handle) in UARTCC26XX.c file. Replaced UARTCC2650_readCancel((UART2_Handle)arg)  to UARTCC2650_resetReceiver((UART2_Handle)arg) in hwi interrupt function.

    The UART and main program no longer stops when received brake signal, frame error, or selected invalid baud rate in PC terminal.

    This is my modified code:

    static void UARTCC2650_resetReceiver(UART2_Handle handle)
    {
        unsigned int                 key;
        UARTCC2650_Object            *object;
        UARTCC2650_HWAttrsV2 const  *hwAttrs;
    
        /* Get the pointer to the object */
        object = handle->object;
        hwAttrs = handle->hwAttrs;
    
        /* Clear error flags */
        UARTRxErrorClear(hwAttrs->baseAddr);
    
        /* Disable UART receiver */
        HWREG(UART0_BASE + UART_O_CTL) &= ~(UART_CTL_RXE);
    
        /* Disable RX interrupts */
        UARTIntDisable(hwAttrs->baseAddr, UART_INT_OE | UART_INT_BE | UART_INT_PE |
                                          UART_INT_FE | UART_INT_RT | UART_INT_RX);
    
        /* Disable interrupts to avoid reading data while changing state. */
        key = Hwi_disable();
    
        /* Read RX FIFO until empty */
        while (((int32_t)UARTCharGetNonBlocking(hwAttrs->baseAddr)) != -1);
    
        /* Reset RingBuf */
        object->ringBuffer.count = 0;
        object->ringBuffer.head = object->ringBuffer.length - 1;
        object->ringBuffer.tail = 0;
    
        /* Set size = 0 to prevent reading and restore interrupts. */
        object->readSize = 0;
        Hwi_restore(key);
    
        object->readSize = 0;
    
        /* Reset the read buffer so we can pass it back */
        object->readBuf = (unsigned char *)object->readBuf - object->readCount;
        object->readCallback(handle, object->readBuf, object->readCount);
    
       /* Reload receiver */
       HWREG(UART0_BASE + UART_O_DR) = 0;
       HWREG(UART0_BASE + UART_O_ECR) = 0;
    
       /* Enable RX */
       HWREG(UART0_BASE + UART_O_CTL) |= UART_CTL_RXE;
    
       /* Enable RX interrupts */
       UARTIntEnable(hwAttrs->baseAddr, UART_INT_RX | UART_INT_RT |
                     UART_INT_OE | UART_INT_BE | UART_INT_PE | UART_INT_FE);
    }

  • Hey Laszlo,

    Glad you got it working. Thank you for sharing your code. I'll be closing this thread, please start a new one for any other queries.

    BR,
    Seong