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/CC3220SF-LAUNCHXL: How to properly handle UART Read when unexpected data length occurs?

Part Number: CC3220SF-LAUNCHXL

Tool/software: TI-RTOS

Dear TI Team,

I am currently working on a project with CC3220SF-LAUNCHXL. I have questions about UART Read operation (callback mode).

Assume that I expect data frames of length 10 bytes and use the following code to enable UART Read.

UART_read(uartHandle, rxBuffer, 10);

If all incoming frames had the correct length, there would not be any issues. However, we know it's not always the case. (rxBuffer can store more than 10 bytes)

Scenario 1: shorter than expected

Imagine due to a power outage, the data sender manages to send only 5 bytes. In the case, UART Read will simply not return and wait for remaining bytes.

Then when another data frame with correct length arrives, UART Read will return, but the data is wrong (5 bytes of the first frame + 5 first bytes of the second frame).

Scenario 2: longer than expected

We may also received longer frames. Imagine if we receive 12 bytes, the current UART Read will return the correct data, but the next Read will be corrupted.

Trials:

I tried a timer with an isReading bool variable to prevent the scenario 1

and

close/open uartHandle before calling every next Read to prevent the scenario 2.  (I should have called readCancel before) 

However, both trials didn't work very well. They are not stable, usually after some iterations, they stops working.

If possible, I would be grateful if you could teach me how to handle these two situations. 

Thanks in advance.

  • Hi Stage RD,

    First I'd like to point you to some additional reading on the UART driver found in the SDK.

    Go to C:\ti\simplelink_cc32xx_sdk_1_60_00_04\docs\tidrivers\doxygen\html and open the "_u_a_r_t_8h.html" file.

    The uart_read function will wait until the buffer is full when in UART_RETURN_FULL mode (Binary data). What you are concerned about is the responsibility of the application. If you receive too few or too many bytes the protocol your design will need to handle this.

    One way to handle this would be to include some header to each transmission to let the device know that a new transmission is beginning and how many bytes to expect. Then you can better handle scenarios where you don't receive the expected number of bytes (maybe even requesting the same data again if possible).

    The following E2E post may provide some insight to you as well: e2e.ti.com/.../2384799

    Hope this helps,
    Kevin