• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 325 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.

AM625: UART issue

Ethan Tian
Intellectual 1872 points
Part Number: AM625
Other Parts Discussed in Thread: SK-AM62B-P1

Tool/software:

Hi experts

SDK: SDK9.0 RT-LINUX

Baud rate: 3M, data bit 8, no parity, stop bit 1.

Phenomenon: There is a certain probability that the interval between bytes of the sent message will become larger.

Specific description:

For example, to send a three-byte message, the application layer calls write(fd,buff,3);

Send a three-byte message (possibly more).

Most of the time it's normal.

Just use an oscilloscope to see that the three bytes are sent together.

 

However, there is a certain probability that once every few seconds, a message will be sent with a large gap between bytes.

As shown in the figure, the first byte is sent first, then after the stop bit of the first byte, it stays for about one byte before sending the next byte.

 

The place where it stays may be any position in the current message, and it basically stays or intervals for one or two bytes.

Influence:

Customer's module communicates at 3M baud rate and is strictly processed according to the serial port communication reception. If the interval between bytes exceeds 1 byte, it is considered that the message has ended and the module discards the current message.

Affects communication efficiency.

Could you give some comments on this issue?

  • 0
    TI__Guru**** 174211 points

    Hi Ethan,

    The SDK rootfs provides a UART program called "serialcheck", it can send a file to UART with specified baud rate.

    Can you please measure the UART bus when sending a big file using serialcheck with 3M baud, to see how soon will you see the 1 or 2 bytes gap?

    Please also test with the latest SDK9.2 to see if the issue still happens. v9.2 has a PLL fix, we want to rule out if the issue is PLL related.

  • 0 in reply to Bin Liu
    TI__Intellectual 1872 points

    Hi Bin

    Thanks for your reply.

    This method is not very good to test. If they send a large file, for example, a buffer is 2K, every 2K will have a delay. Also, it is not clear how long each write of this program will take, and each write will have a delay
    Also, if there is no event, It is difficult to find if interbyte delay is created in the process
    Their case  is the master and slave communication, and when the slave does not reply, they capture the waveform and compare it

  • 0 in reply to Ethan Tian
    TI__Guru**** 174211 points

    Hi Ethan,

    Please let me know how I can reproduce the issue on SK-AM62B-P1 EVM?

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hi,Bin.

    As the picture。 AM62 communicate with the mcu, use 3M baud. Per-millisecond send one packet about 3 bytes. Mcu check the packet by strict byte time.

    If the bytes delay time over byte-time, mcu will  ignore the dates until next good packet.

    A few seconds can reproduce one time this issue.

    It's hard to reproduce on EVM or use other app. It's hard to capture the wareform.

    Maybe the best way to reproduce the issue  is using MCU to receive the packet from AM62 and calculate the byte time.

  • 0 in reply to jie wu
    TI__Mastermind 20455 points

    Hello,

    Bin is out of office until the end of next week. Please expect a delayed response.

  • 0 in reply to jie wu
    TI__Guru**** 174211 points

    Hi Jie,

    Sorry for my late response.

    If it is difficult to create a test case to reproduce the gap behavior on the EVM, how do you confirm if the gap is generated -

    1. either by the UART controller when its TX FIFO has enough data, or
    2. the TX FIFO is empty but Linux kernel doesn't schedule UART driver soon enough to fill the TX FIFO?

    However, the bottom line is why the UART module assumes the data received would be contiguous and discards the message when a gap happened? Why the module firmware doesn't implement a high level protocol to request message resending when incomplete message is received? I am not aware of any standard which requires the UART data transmit should not have a gap.