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.

CCS/CC2640R2F: serial port communication error when use different settings

Part Number: CC2640R2F

Tool/software: Code Composer Studio

Question 1:

When I use the UART_Params structure to initialize the serial port, it is found that the serial port can not work normally when the data bit dataLength is set to 5 and 6, and the output information is a random code. When using 7 and 8 data bits, the output information of the serial port is correct. What's the reason? thanks!

Question 2:

Stop bits and check bits are set correctly, can be used.

But there is a strange phenomenon, for example, the setting stop bit is 1, the parity bit is Odd, if the serial port configuration is the same as the settings, then the use is OK.

If the checkbit error uses even, sends a piece of data, switches back to the Odd, and sends the message to find the serial port dead (other normal: GPIO, timers, including Bluetooth signals, etc.)

What is the reason for this?

Initialization function: UART_Params_init (&params);

Baud rate setting: params.baudRate = 115200;

Data bit setting: params.dataLength = UART_LEN_8;

Stop bit settings: params.stopBits = UART_STOP_ONE;

Check bit setting: params.parityType = UART_PAR_EVEN;

  • Hi Cary,

    Regarding Q1, I have tested this myself and do not see a problem with 5 and 6 bit mode, the data I see on the output is the expected data. Are the source you are using to look at the data setup correctly? If so, can you provide an example where you can reproduce this that I can test?

    Regarding Q2, do you mean you are switching parity from even to odd on the the terminal size? There is a known bug in the older version of the UART driver where some rare combinations of parity and framing errors can cause the UART driver to stop.

    There will be a new SDK release for the CC2640R2 in the upcoming weeks that should include a fix for this. If you want to try to see if it makes a difference, I believe you can use the UARTCC26XX.c driver from any of the existing 2.10 SDKs (such as the CC13x0 SDK).

  • Hello Cary,

    I tested this on the uartecho TI-RTOS driver example successfully.

    1.

    How do you read the data? If you use a COM port emulator you need to configure the format correctly to receive and decode it correctly. I tested this successfully with the Realterm emulator:

    2.

    It worked with even parity also as long as I set this in the emulator.

  • Dear Eirik,
    Please help to check the SDK VERSION that we use and our action. thanks!
    Use the npi_tl_uart.c under C:\ti\simplelink_cc2640r2_sdk_1_40_00_45\source\ti\ble5stack\npi\src\unified ;
    Use ble_examples-master in the SDK wiht version: simplelink_cc2640r2_sdk_1_40_00_45;
    The detailed information is:
    ParamsUART.dataLength = UART_LEN_8 changed to paramsUART.dataLength = UART_LEN_5 which is in initialization function SDITLUART_initializeTransport of sdi_tl_uart.c file.
  • Hello Cary,
    The NPI UART Frame format is bytes only. The transport layer is designed to handle bytes over uart (UART_LEN_8).
  • Dear Eirik,
    How to edit the code that we want use dataLength 5 or 6?
    Please help to give your guidance. Thanks very much!
  • Hello Cary,
    Why do you need to use 5 bit data length?
    We do not have a guide for this. I believe it would be a big job as you would need to add a custom UART layer that collect several 5 bit packets into the byte format.
  • Dear Eirik,
    Noted! The demand of the terminal users. Thanks!