• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 372 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2640R2L: Issue related to UART in CC2640R2L

Bhavin Parmar
Expert 1550 points
Part Number: CC2640R2L
Other Parts Discussed in Thread: CC2640,

Hi Team,

We are facing one issue with CC2640 related to UART. UART unable to respond to our queries, if queries are sent frequently. During the analysis we came to know that  reason of the problem is UART_read( ) call of TI RTOS takes considerably higher time than expected.

BY using CRO, we measured and confirmed the UART_read( ) came out from blocking mode after 28 ms (approx ), after the last bit of Rx byte received.

This experiment conducted at 1200 baud rate.

Has anybody come across this kind of problems?, and any solution or workaround available for this issue?

 

Device/Test/setup information

Device: CC2640R2L

SDK: simplelink_cc2640r2_sdk_4_20_00_04

Example: Simple Central.

 We are using UART as only task (Other tasks disabled to focus on this issue) with following configuration. We did single byte echo experiment in which we observed 43ms to 62mS delay (between Tx and Rx byte in PC serial terminal) in receiving echo.

Same observation we observed with Launch Pad using same example as well as readymade UART Echo from driver example code.

Refer the below code snippet which is used for single byte echo test with CRO

Observations

  1. After receiving the last bit of the Rx byte, it takes approx. 28 mS to come out from UART_read( ). Refer the time gap between two vertical cursors (28 ms) after the last bit of Rx byte in below picture
  2. UART_write( ) seems working fine (No additional delay ) 

Regards,

Bhavin 

  • 0
    TI__Mastermind 42320 points

    Hi Bhavin,

    I have assigned an expert to comment on this. In the meantime, you mentioned that this behavior is observed in an  unmodified UART Echo example? Can you verify if you are able to see this behavior on the 5.10 SDK? Does the observed time gap vary when modifying the baud rate?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Expert 1550 points

    Hi Jan,

    We did further experiment and this time we read 4 bytes and 22 bytes as no of byte to be read in UART_read( ) API. Observation is that delay of 28mS is constant irrespective of number of Bytes.

    28mS delay comes between last bit of last byte and coming out of UART read API.

    Following is the CRO image.

    Regards,

    Bhavin P

  • 0 in reply to Bhavin Parmar
    TI__Guru** 101460 points

    Hi Bhavin,

    These are interesting findings.

    What would be your goal in terms of delay?

    I am currently looking into our UART driver to understand if the delay is coming from the hardware or rather the software. Please bear with me.

    Kind regards,

  • 0 in reply to Clément
    Expert 1550 points

    Hi Clement,

    We are using byte by byte reading which accumulates 28mS delay in every byte received, finally it affects throughput to other devices connected to this.

    Regards,

    Bhavin P

  • 0 in reply to Bhavin Parmar
    TI__Prodigy 150 points

    Hi Bhavin,

    Unfortunately the hardware we had available on the CC26x0 family required some workarounds in software that end up in the delays you are seeing. If you can RX in larger blocks, it is possible to spread the delay so thin it no longer matters. If your situation mandates that you RX byte by byte, I can think of a couple of ways to improve the situation:

    • Ditch the UART driver and call driverlib directly - for a one-byte-at-a-time polling-mode use case this would be fairly straightforward. It will take up more CPU time with less options for the device to go into standby or idle. This file would be under source/ti/devices/cc26x0r2/driverlib/uart.h and defines all the low level control functions that are used by the UART driver.
    • Have a look at the UART2 driver in a more recent CC26X2 sdk. There is a new end of transmission interrupt on CC26x2 so this will not work out of the box for the 2640, but it should be feasible to trim the driver down into only the polling mode components, which do not rely on the new interrupt. In the end this will look similar to the first option but it presents a different way to approach the work.

    I don't think there is a good way to modify the existing UARTCC26XX driver on 2640 to remove this delay without it becoming more work than the options above. Let me know if you have questions about these options or how you would go about implementing them.

    Thanks
    James