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

AM3352: Linux/AM3352: rs485 receive data loss

yan ma
Prodigy 40 points
Part Number: AM3352
Other Parts Discussed in Thread: AM625

Tool/software:

Hi Sitara support Team,

We are encountering issues with the RS485 reception on the AM3352.

Environment:

  • SDK version：rt-am335x-evm-04.03.00.05
  • kernel version：linux-rt 4.9.69
  • rs485(High level enables transmission, low level enables reception.)

issue description：

        After sending data via RS485, the direction signal is pulled low too slowly, causing the received data to be incomplete.

The blue pin is for transmission, the purple pin is the direction control (high enables transmission, low enables reception), and the green pin is for reception. Normally, the direction control should be pulled low immediately after transmission, but in this case, it is pulled low too late, during the middle of reception, causing some data to be missed.

I have one question:

The AM3352 emulates RS485 in the serial port driver, requiring manual control of the direction signal in 8250_port.c. There is an issue where increased CPU load causes the direction signal to change slowly. Can this be optimized?

Because I know that the AM625 serial port can be directly configured into RS485 mode, allowing hardware to directly change the direction pin.

  • 0
    TI__Guru* 84075 points

    Hello 
    We no longer support 4.9 kernel, it is very old. Have you confirmed that you see the issue with the latest SDK and kernel ?

    I have assigned this to our UART expert, but please expect delays as Thursday is a US holiday and Friday the expert is out. 

    Regards

    Mukul 

  • 0 in reply to Mukul Bhatnagar
    Prodigy 40 points

    Thank you for your response; I look forward to hearing from the expert.Our product currently uses the 4.9 kernel; we haven't tried the latest kernel yet.

  • 0
    Prodigy 40 points

    I'll add some pictures.

    The purple signal is the receive pin, the blue signal is the transmit pin, and the yellow is the direction control pin.

    This is a normal waveform:

    This waveform shows the problem; the direction of the quotation marks changes very late：

    There's another image for reference,

  • 0 in reply to yan ma
    TI__Guru**** 169071 points

    Hi Yan,

    As Mukul mentioned kernel v4.9 is very old and no longer supported.

    yan ma said:
    The AM3352 emulates RS485 in the serial port driver, requiring manual control of the direction signal in 8250_port.c. There is an issue where increased CPU load causes the direction signal to change slowly. Can this be optimized?

    You might want to test with the RT kernel in the latest Processor SDK v9.1 to see if the latency is improved.

    yan ma said:
    Because I know that the AM625 serial port can be directly configured into RS485 mode, allowing hardware to directly change the direction pin.

    Unfortunately AM335x UART module does not have such dedicated RS485 DE control pin. It replies on the kernel driver to manipulate the RTS pin for DE control.

  • 0 in reply to Bin Liu
    Prodigy 40 points

    Hi Bin,

    Thank you very much for your reply. I feel that it has little to do with the kernel version.

    I added some print statements to monitor the execution time and I noticed that sometimes the interrupt function is executed very late (the direction signal pin is pulled low during the interrupt). Given that we are operating on an RT kernel, is it possible that the scheduling of other real-time tasks is resulting in this delay in interrupt handling?

  • 0 in reply to yan ma
    TI__Guru**** 169071 points

    Hi Yan,

    Each (major) kernel version might have its scheduling algorithm changed, so I think it is worth to test with SDK9.1, given that kernel v4.9 is no longer supported on this forums.

    Please also try to increase your RS485 user space application priority to see if it improves the UART interrupts.