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.

AM3352: UART data lost on USB connect

Part Number: AM3352

Hi,

I am using Processor SDK Linux version 06_01_00_08.
Recieving UART data may be missed due to hot swapping of USB.
This phenomenon is reproduced on BeagleBoneBlack as well as my target board and can be easily reproduced by performing an operation that repeats ON / OFF of USB VBUS as shown below.

====
[usb_off_on_loop.sh]
#!/bin/sh -x

while :
do
echo 'usb1' > /sys/bus/usb/drivers/usb/unbind
echo 0 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
sleep 1
echo 255 > /sys/devices/platform/leds/leds/usb_hub_power/brightness
echo 'usb1' > /sys/bus/usb/drivers/usb/bind
done
====

Is there a way around this problem?
Is the latest version of the UART driver of the SDK enabled for DMA reception?


Best Regards,
H.U

  • Hi,

    I am not aware of this problem. Please provide more detail to help me reproduce the issue and take a look.

    Do you have any usb device attached to the USB1 port?

    Which UART port do you test?

    What UART device is connected to the AM335x UART port?

    What program do you use on AM335x to receive UART data?

  • Hi Bin Liu,

    Thank you for your reply.

    The Beaglebone Black connects to any USB device on USB1 port and the UART4 port connects to the PC.
    The PC executes the attached macro (Send_data.ttl) from a terminal such as Teraterm to the UART4 port and sends continuous data.

    The firmware is used with the attached dts file (BBBtest.dts)using the following pre-built image.

    http://software-dl.ti.com/processor-sdk-linux/esd/AM335X/latest/exports/am335x-evm-linux-sdk-bin-06.01.00.08.tar.xz


    1537.files.zip



    The log of UART4 port is obtained as follows.

    # stty -F /dev/ttyS4 115200
    # cat /dev/ttyS4 > uart4.log &


    Best Regards,
    H.U

  • Hi Bin Liu,

    I am still expecting your response.
    Please let me know any other information you need to reproduce this issue.

    Best Regards,
    H.U

  • Hi,

    Sorry, I am in the middle of a work and haven't got time to run the test yet.

    But I noticed that your Teraterm script enables hw flow control, but the UART4 connection doesn't have RTS/CTS lines, so hw flow control won't work. Without hw flow control UART data loss is expected when CPU is unable to keep up with the data transmitted on UART.

    Can you please try to bring out UART4 RTS/CTS lines and enable hw flow control on AM335x UART4 as well to see if data loss still happens?

  • Hi Bin Liu,

    I also tried connecting RTS / CTS line between PC and BBB. As a result, a part of the UART received data was also lost.
    Attach the DTB file I am using. Can you check it?

    am335x-boneblack-test-uart.zip

    Best Regards,
    H.U

  • Hi H.U,

    Not only connect RTS/CTS, but did you enable hw flow control?

    Please use the following command on AM335x instead, and also enable hw flow control on the PC.

    # stty -F /dev/ttyS4 crtscts 115200

  • Hi Bin Liu,


    I use the following command, and the PC side also has HW flow control enabled.

    # stty -F /dev/ttyS4 crtscts 115200


    Cloud you try it in your environment? This issue will be reproduced soon.

    Best Regards,
    H.U

  • Hi H.U,

    Thanks for the update. I will try to reproduce it.

    We started working from home due to COVID-19. At home I don't have the same work efficiency as in office, so my progress will be slower, but I will keep you posted.

  • Hi H.U,

    I replicated the same setup as yours, except I connected BBB UART to a Linux PC through a FTDI cable.

    I am able to see the UART4 data loss when hw flow control is disabled (stty -F /dev/ttyS4 -crtscts 115200 on BBB, and stty -F /dev/ttyUSB1 -crtscts 115200 on PC). For example, the following transfer is shorter:

    1695 2020-03-18 14:15:57 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
    
    1696 2020-03-18 14:15:57 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLM                
    1697 2020-03-18 14:15:57 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
    

    and the BBB Linux console has the following kernel message when data loss happens.

    [  472.733354] ttyS ttyS4: 1 input overrun(s)

    But the data loss doesn't happen when hw flow control is enabled (stty -F /dev/ttyS4 crtscts 115200 on BBB, and stty -F /dev/ttyUSB1 crtscts 115200 on PC). So I suspect you didn't use hw flow control properly.

    Please ensure the BBB UART4 CTSn line connects to PC UART RTSn line, and BBB UART4 RTSn line connects to PC UART CTSn line.

    BBB CTSn --> PC RTSn
    BBB RTSn --> PC CTSn

    If you checked your CTSn/RTSn connection is correct but data loss still happen, please check if your PC UART hw flow control works - pull PC CTSn line to high voltage, then use a scope to check PC TXD line when PC application (teraterm script) is sending data, the scope should NOT see any activity when PC CTSn is high.


  • Hi Bin Liu,

    I ultimately want to prevent incoming data loss without hw flow control.
    However, In the documentation of the next SDK version, I found that data loss will occur if hw flow control is not enabled.


    [It is always recommended to connect HW flow control lines for UART communication. Also, software should enable HW flow control explicitly. Otherwise, there will be data loss and data corruption.]

    software-dl.ti.com/.../UART.html


    In other words, is it impossible to prevent data loss when hw flow control is disabled?
    Also, the above document is the SDK future version (06_02_00_81) that has not been released. Is it the same for the current SDK version (06_01_00_08)?


    Best Regards,
    H.U

  • The best way to prevent UART RX data loss is using hw flow control.

    Think about how UART works - UART has a very small RX FIFO buffer, typically 16 to 64 bytes. If the TX end keeps sending data but the RX CPU is busy on other tasks and is unable to offload the RX FIFO fast enough, the RX FIFO will overflow/overrun, RX data loss happens. Linux is a multi-task OS, it is not guaranteed the CPU is always ready to serve UART before RX overrun happens. So you'd better to use UART hw flow control to prevent UART data loss.

  • Hi Bin Liu,

    I think that if DMA is used, data can be received even if the CPU is busy. If so, is the Processor SDK not enabling DMA?
    Or is it not possible to avoid this issue using DMA?

    Best Regards,
    H.U

  • Hi H.U,

    With the device tree file you provided enabling uart4, DMA is not enabled for UART4.

    Enabling DMA for UART4 could probably improve the situation a bit, but it won't solve the issue completely.

    Mainly you can consider there are two buffers in the UART RX path, one is the UART RX FIFO, the other is the RX buffer in the kernel TTY framework. The UART driver is responsible to move data from the RX FIFO to the TTY buffer using CPU or DMA, and applications read data from the TTY buffer which can only use CPU.

    So if the CPU is busy on something and doesn't have bandwidth to service the application, the TTY buffer will overflow, and data loss still will happen. DMA doesn't help in this scenario, only hw flow control can.

  • Hi Bin Liu,

    Thank you for all your assistance.
    I really appreciate your help in clearing this issue.

    Best Regards,
    H.U

  • Hi H.U,

    You are welcome. I am glad it helps.