• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 131 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.

SK-AM62P-LP: Issue with the UART Communication

Raj Kumar
Intellectual 358 points

Part Number: SK-AM62P-LP
Other Parts Discussed in Thread: AM62P

Hi Expert,

We are currently using the AM62P evaluation board with the Debian Trixie OS.

In our application, UART5 (/dev/ttyS5) is configured as the master with the following settings:

   8-bit mode

     Full duplex

    No parity

    115200 baud rate

    1 stop bit

The slave controller is configured with matching parameters. Initially, communication works as expected, and data exchange between devices is successful.

However, during long-duration operation, we are observing an issue on the UART master side. Specifically:

The slave continues to transmit data correctly.Using a PicoScope serial decoder, we can see valid data on the UART RX pin of the AM62P.

The UART receive buffer on the master is also updating correctly (we continuously monitor buffer size for debugging, and it changes as expected).

We are able to read from the buffer.

Despite this, the application does not reflect updated data.

If we perform a power cycle and restart the application, the system resumes normal operation.

Questions:

1. If the slave is transmitting correctly and the master buffer is receiving data, why might the application fail to update?

2. Could this be related to driver issues, buffering, threading, or a blocking condition in user space?

3. Are there known issues or recommended debugging steps for UART handling on the AM62P (Debian Trixie)?

Any guidance or suggestions would be appreciated.

  • 0
    TI__Guru**** 180986 points

    Hi Raj,

    Raj Kumar said:

    The UART receive buffer on the master is also updating correctly (we continuously monitor buffer size for debugging, and it changes as expected).

    We are able to read from the buffer.

    Please explain what exact the buffer is? somewhere in kernel or Linux userspace? Any additional log or information would help me understand where in the RX path the data have been reached to.

    Raj Kumar said:
    Despite this, the application does not reflect updated data.

    Please explain what the application is, your own program or something from the open source community?

  • 0 in reply to Bin Liu
    Intellectual 358 points

    Hi Bin,

    We are currently using a UART kernel driver on the master side for communication. In our application, we are checking the number of bytes available in the kernel buffer using the Linux system call:

    ioctl(fd, FIONREAD, &bytes_avail);

    Since we are transmitting 10 bytes in each cycle, the buffer size (bytes_avail) is observed to change during runtime, which is expected behaviour.

    As part of additional testing, I monitored the serial interface status in the background. The status output indicates that the system is functioning correctly, with no reported errors. The RX and TX byte counters are also updating as expected.please find the attached screenshot for the reference.

    Please let me know if any further analysis or validation is required.

    Thanks & Regards,
    Rajkumar.



  • 0 in reply to Raj Kumar
    TI__Guru**** 180986 points

    Hi Rajkumar,

    First of all, I never saw any terminal program uses FIONREAD ioctl. Then I searched the kernel tty driver framework but I don't see FIONREAD is supported by most tty/serial drivers, except ipwireless and hdlc which are not used by AM62x UART. I am not sure how this ioctl can be used in your program.

    Anyway, please explain your program, how does it read from the UART, and how it gets stuck?