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.

CC2642R: UART2_write sometimes sends data incompletely

Part Number: CC2642R
Other Parts Discussed in Thread: SYSCONFIG

Hello

In a project we are using the CC2642 as a Bluetooth bridge in a system with an additional main application controller. Both controllers communicate via UART to exchange data between the Bluetooth devices and the main application controller.

 

The CC2642 application is based on the multirole example. When data is received from a BLE central device, it is packed into a UART frame with a header and trailer (2 Bytes CRC) and sent using UART2_write() function.

 

Recently we've updated from CC26x2 SDK 4.20.00.35 to 5.10.00.48. Since then we have the problem that sometimes the UART frame is not completely sent by the CC2642 (seen with logic analyzer). In these cases the last byte of the 16-bit CRC is missing in the frame trailer. Our application passes the data completely and successfully to UART2_write() - it doesn't return any error code.

 

I didn't have this problem with the SDK that we had used before. I have seen that many changes have been made to the UART2 driver due to the update. Do you know such an issue?

Notes on our UART setup:

  • 2 Tasks, one for UartRx and the other for UartTx
  • UART read and write mode is set to blocking
  • baudRate is set to 115200
  • Payload data to be sent is passed to the UartTx task via a mailbox
  • UartTx task pends on the mailbox, takes the data, builds the UART frame by attaching a header and trailer to the payload and passes the frame to the UART2 driver

Kind regards

Martin

  • Hi Martin, I will look into our logs for you to best explain this. In the meantime, could you also share your UART2 initialization and setup, and note if there were any additional changes made after updating the SDK.

    Best,

    Tariq

  • Hi Tariq,

    sorry for the late reply.

    The Uart is initialized by the UartTx task:

    UART2_Handle uart;
    static bool initialized = false;
    #define DataUart 0
    
    static void init(){
        UART2_Params uartParams;
        UART2_Params_init(&uartParams);
        uartParams.readMode = UART2_Mode_BLOCKING;
        uartParams.writeMode = UART2_Mode_BLOCKING;
        uartParams.readReturnMode = UART2_ReadReturnMode_FULL;
        uartParams.baudRate = 115200;
        uart = UART2_open(DataUart, &uartParams);
        
        initialized = true;
    }

    After the uart is initialized (initialized == true) the UartRx task waits for data.

    Additionally I've also ported changes from the multirole example - some sysconfig parameter names have changed and a bugfix for a memory leak due to the delayed BLE connection parameter update request.

    Regards,

    Martin

  • Hi Martin, 

    Could you try setting the readtimeout / writetimeout

    For example:

    params.readMode = UART2_MODE_BLOCKING;
    params.writeMode = UART2_MODE_BLOCKING;
    params.readTimeout = UART2_WAIT_FOREVER;
    params.writeTimeout = UART2_WAIT_FOREVER;

    Also would you still see the same issue if you use UART vs UART2?

  • Hi Tariq,

    the UART2_Params hasn't a readTimeout/writeTimeout member. For writing we use the UAR2_write() function and this blocks task execution until all the data in buffer has been writen.

    I've tried the UART driver instead of UART2 driver already before and haven't seen this specific issue. But therefore the controller was unstable during the data transmission and it sometimes missed the start of frame when receiving data. That's why I didn't pursue this approach any further. But I will check this again.

  • Hi Martin,

    I apologize for the confusion, you are correct that UART2_Params doesn't have timeout fields.  The UART2 TI Driver is different from UART as it uses specific UART2_readTimeout and UART2_writeTimeout APIs, each with timeout parameters, to accomplish this function.

    Regards,
    Ryan

  • Hi Ryan,

    After switching to the UART driver, the problem of missing bytes in the frames didn't occur anymore.

    But I have two other issues:

    1. The debug build configuration has logging via UART enabled (it also uses the UART driver) and therefore uses the User UART of the XDS110. Sometimes I get a "Invalid response from the XDS"
      IcePick_C: Error: (Error -261 @ 0xFFFFFEFB) Invalid response was received from the XDS110. (Emulation package 9.3.0.00058)
      This is a known issue https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html#invalid-response-was-received-from-the-xds110. Do you have any news for this?
    2. In an environment with multiple Bluetooth devices (50+), I have observed that the application is now unstable. A deadlock occurs, which I need to investigate further. I have not yet observed this behavior in an environment with fewer Bluetooth devices.
  • I'm glad to hear that you've been able to resolve a few problems.

    1. I do not have any additional information or updates regarding this issue.  Are you using a TI LaunchPad EVM with the shortest USB micro connector cable available?  
    2. Once you have more information, please post a new question on the forum so that a BLE expert can help assist you with this.

    Regards,
    Ryan