• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 683 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.

uart sync issue

gautam jotkar
Expert 1165 points
Other Parts Discussed in Thread: CC2540

Hi all,

I am working with the CC2540 EM kit and I have programmed the chip to make it read data from the UART and transmit the data. However, I am having issues with the timeout of UART RX. For instance, if I expect 10 bytes of data and 9 bytes of data is received, the 1 byte of data missed during current iteration sits on the UART buffer and gets receievd at the next iteration and causes an offset in my packet (which causes many problems when trying to find the sync word and so on ).

My questions are:

1) Is there a way for me to flush what is on the UART buffer after I have grabbed the number of bytes that I want?

2) Is there a method to timeout the UART operation when no response is obtained on RX line?

If yes pls explain

Thanks in advance.

  • 0
    Prodigy 210 points

    Hi,

    I have the same problem as yours, I send out "ABCDEFG" from an external MCU to the CC2540 via the UART, the CC2540 received interrupt several times, sometimes it receives "ABC", and then "DE", "FG", sometimes "AB", "CDEF", "G".

    It works fine with SDK 1.2.1

  • 0 in reply to YC Poon
    TI__Mastermind 23440 points

    Hi,

    This is the way asynchronous communication works. The UART is DMA driven, and the incoming data is polled from the RX buffer asynchronously of whatever goes on on the physical layer.

    You will have to, in this case and others, to create your code in such a way that it does not need for example 10 bytes.

    Otherwise, use the Hal_UART_RxBufLen function to see if you have enough data available and wait if not.

    BR,
    Aslak 

  • 0 in reply to Aslak N.
    Expert 1165 points

    hi aslak,

    The fact that u mentioned about asynchronous communication is understandable and valid.

    I dint get what u meant in the next statement, can you please clarify?

    thanks

  • 0 in reply to gautam jotkar
    TI__Mastermind 23440 points

    Hi,

    Not sure which statement you are referring to.

    But imagine this. Thread A is putting stuff into a circular buffer. Thread B is polling the buffer sometimes. Do you think you are guaranteed that Thread B will always poll exactly when one message is correctly received in the buffer, or do you imagine it's possible that Thread B will sometimes poll in the middle of a transfer and, not knowing anything about what is to be transferred, just takes what is there?

    Or did I perhaps misunderstand, and the entire message never arrives completely?

    Best regards,
    Aslak 

  • 0 in reply to Aslak N.
    Expert 1165 points

    Hi aslak

    I totally understand and agree with you on the working principle of UART circular buffer, and asynchronous communication.

    I dint understand what u meant when u said "You will have to, in this case and others, to create your code in such a way that it does not need for example 10 bytes." that is what i had referred as 2nd statement.

    Also please tell me how can I insert delay in the UART routine so that i can also receive the delayed data packets as well. Is using timers is the only way?

    Regards

    Gautam

  • 0 in reply to gautam jotkar
    TI__Mastermind 23440 points

    Hi Gautam,

    You need to not expect 10 bytes or whatever it is that constitutes an entire communication frame / telegram, but you must create your serial data parser so that it reads in and parses whatever is available at the time of the RX callback.

    For instance read in 1 byte at a time and when nothing more is available, wait until the next RX callback. You may also use Hal_UART_RxBufLen() to get info on how much has been fed into the RX buffer at the time of the callback.

    Best regards,
    Aslak