• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 102 subscribers
  • Views 934 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM4379: UART communication ISSUE

Fabio Soriano
Intellectual 2315 points
Part Number: AM4379

Hi Team,

I received the following request from a customer I'm following:

################################################################################

We are currently using the 800MHz version of this CPU in our smart grid node Project.

 

-        We are using the Linux distribution published on the TI website (kernel version: 4.14)

-        AM4379 is the main processor but we also have other processors in our device.

The other processors communicate with AM4379 over RS-422/UART.

-        In our full configuration we use 5 UART each with 1 Mbps speed.

-        When we noticed the packet error in our communication, we used serial check and serial stat SW from TI

to diagnose the problem.

-        We get Rx buffer overrun error for a certain percentage of the frames received by AM4379.

We observed that some zero bytes are inserted into our data frames in case of error.

-        The error rate decreases when we reduce the active UART channels from 5 to 1 but there is still some error.

-        The error rate also decreased when we reduced the speed from 1Mbit to 500 Kbps but there is still some error.

And this is not a good solution because we need fast data transfer for some device features. We hope we will be able

to use the UART even with higher baud rates (at least 2-3 Mbps) in some coming projects.

-        Currently we handled the packet error with a data link protocol but I hope you can propose a better

solution to this issue.

  • 0
    TI__Guru*** 125176 points
    Hi Fabio,

    I am wondering if the problem is due to the system is loaded and unable to offload the UART RX FIFO fast enough.

    - What other processes are running on the system while UART is receiving data?
    - What cpufreq governor is used?
    - Can the customer check the 'top' command for the system load? especially for the time serving the hardware and software interrupts.
    - Is the error rate decreased further if lower the baud rate to 256Kbps?

    The UART fifo is 64 bytes, and RX interrupt trigger is set to 48 bytes in the driver (drivers/tty/serial/8250/8250_omap.c) with micro RX_TRIGGER. Can the customer decrease RX_TRIGGER, for example to 32 bytes, to see if it improves the situation?
  • 0
    TI__Guru*** 125176 points
    Hi, I haven’t heard back from you, I’m assuming you were able to resolve your issue. If not, just post a reply below (or create a new thread if the thread has locked due to time-out). thanks.
  • 0 in reply to Bin Liu
    Prodigy 105 points

    Hi Liu,

    I will try to answer your questions. We are still working on the problem, not fixed yet. As you said, we think that problem is related to system load.

    - What other processes are running on the system while UART is receiving data?

    Webserver, GUI Process, Database Management Process, Ethernet Base Industrical Comm Protocol Processes and 5 Serial Port Communication Manager Process

    - What cpufreq governor is used?

    Cpu Freq Governor is "ondemand"


    - Can the customer check the 'top' command for the system load? especially for the time serving the hardware and software interrupts.

    Top command result is down below. Numbers are not that high.

    - Is the error rate decreased further if lower the baud rate to 256Kbps?

    At the beginning we worked with 1Mbps and we were getting lots of overruns. We are using 500Kbps now, error rate gets lower.

    I could not tested 250Kbps and Kernel Modification yet. I will let you now whenever i do it.

    When we search TI Wiki for  DMA support  is not avaliable for AM437x, why is that? Do TI have a plan to extend it?  

    processors.wiki.ti.com/.../Linux_Core_UART_User's_Guide

  • 0 in reply to cihangir.odabas
    TI__Guru*** 125176 points

    Hi,

    cihangir.odabas said:
    When we search TI Wiki for  DMA support  is not avaliable for AM437x, why is that? Do TI have a plan to extend it?  

    The DMA is disabled in UART driver for AM437 is due to an issue that UART port 1, 2, and 3 could trigger DMA pre-maturely and result in underflow condition leading to data corruption.

  • 0 in reply to Bin Liu
    Prodigy 105 points

    Hey Liu,

    Can you interpret system load and top command results?

  • 0 in reply to cihangir.odabas
    TI__Guru*** 125176 points
    Hi,

    The system load shown in the top command seem light, so it seems not to be an issue if the result was captured during uart rx error happens.
    Have you tried to lower the RX interrupt trigger threshold I suggested above?
  • 0 in reply to Bin Liu
    Prodigy 105 points

    Hey Liu,

    I am testing your suggestion. I am testing serial port status with serialstats software. (It is given by TI wiki processors.wiki.ti.com/index.php/Linux_Core_UART_User%27s_Guide)

    I tried different versions of RX_TRIGGER.

    These are the results:

    Serial Comm. 500 kBps, RX_TRIGGER 48 (default) : 56 overrun over 500k RX Byte

    Serial Comm. 500 kBps, RX_TRIGGER 32 : 47 overrun over 500k RX Byte

    Serial Comm. 500 kBps, RX_TRIGGER 16 : 18 overrun over 500k RX Byte

    Serial Comm. 500 kBps, RX_TRIGGER 8 : 19 overrun over 500k RX Byte

    Serial Comm. 500 kBps, RX_TRIGGER 1 : 0 overrun over 500k RX Byte

    According to results, your suggestion is helping but not completely. RX_TRIGGER 1 is  a little bit extreme, but i want to see the results. I can try with higher speeds if you want. What is your opinion?

    I came across to similar thread, but we don't use DMA but still get the same results. https://e2e.ti.com/support/processors/f/791/p/632011/2345584

  • 0 in reply to cihangir.odabas
    TI__Guru*** 125176 points
    Hi,

    I don't have a board which has 4~5 uart ports available, but I spent some time testing on a single uart port on Beaglebone Black with Serial DMA disabled, and found the similar results as you observed - the higher baud rate, the higher fifo overrun frequency. After consulted with our software dev team, the comment is - it is almost impossible to avoid hw fifo overrun without using hw flow control, due to the nature of ISR scheduling in Linux, plus TTY buffer overrun could also happen if user space application doesn't consume data fast enough, which has even lower scheduling priority in Linux. So the recommendation is to use hw flow control to avoid fifo overrun.
  • 0 in reply to Bin Liu
    Prodigy 105 points

    Hey Liu,

    Is it possible to test serial communication on your board with HW Flow Control up to 3 Mbit to see overrun numbers?

  • 0 in reply to cihangir.odabas
    TI__Guru*** 125176 points
    Hi,

    I currently don't have a setup which brings out RTS/CTS signals for HW flow control, but we shouldn't see overrun when hw flow control is enabled, instead the throughput would be lower due to the flow control.
    Do you still see overrun when hw flow control is enabled?
  • 0 in reply to cihangir.odabas
    TI__Guru*** 125176 points
    Hi, I haven’t heard back from you, I’m assuming you were able to resolve your issue. If not, just post a reply below (or create a new thread if the thread has locked due to time-out). thanks.