• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 631 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.

Linux/PROCESSOR-SDK-AM335X: Experiencing Serial Write fails

Brandon Edmonds74
Prodigy 160 points

Part Number: PROCESSOR-SDK-AM335X
Other Parts Discussed in Thread: CC2531

Tool/software: Linux

Hi,

I am experiencing the following issue on a AM335X based machine. Uname -a reports am335x-evm 4.1.18-gbbe8cfc.

Occasionally the system stops writing to ACMx serial devices successfully, although the handle appearas to be fine as reads complete successfully.  The error when the write fails is "resource not available".  

Debug code was added before the attempt to call :write(). A call to select() was added, which can be used to indicate if a serial port write will complete successfully.  As expected, the system would get into a state where the select would timeout, indicating an attempt to write on the port would fail.

Finally I discovered the TIOCOUTQ ioctl call, which returns the number of bytes in the OS serial write buffer.  The application was updated to display the number of bytes in the buffer just before the call to select. Normally the value reported is zero, and everything works fine. Occasionally I would see the following.

> TIOCOUTQ IOCTL Reports 0 bytes in the OS buffer

> Application writes 13 bytes

> TIOCOUTQ IOCTL Reports 1280 (0x500) bytes in the OS buffer. 

When the ioctl call returns 1280 the call to select fails.

This value never changed over time, and using tcflush(mPortHndl, TCOFLUSH) does not clear the buffer.

Examining the release notes, i have found a reference to a known issue that may shed some light on this problem, but I am unable to find any detail other than the title.

"LCPD-8636 Serial corruption being seen in kernel".

  1. Any thoughts?
  2. Does this behavior sound familiar to anyone? 
  3. How can I access the details of LCPD-8636?
  4. Any questions for me?

Thanks for your time,

Brandon

  • 0
    TI__Guru**** 175031 points
    Hi Brandon,

    Is this on USB serial or UART serial? if former, what is the USB serial device?
    Can you please test with the latest Processor SDK Linux v5.2 kernel to see if the issue also happens?
    LCPD-8636 related to linux console corruption which happens during input 'root' for login in automation, it seems not related to your issue, at least at this point.
  • 0 in reply to Bin Liu
    Prodigy 160 points

    Thanks for the response.

    This has happened with 3 or 4 different types of devices, one of which is a CC2531.  They all use the usb_acm driver.

    Changing the SDK version is not an option at this point.

    I assume this driver runs in kernel space. Have there been any instances of a serial application corrupting the driver?

    Thanks again,

    Brandon

  • 0 in reply to Brandon Edmonds74
    TI__Guru**** 175031 points
    Brandon,

    Thanks for confirming this is with USB serial devices. I am not aware of such corruption problem.

    Yes, the USB ACM driver runs in kernel space, and exposes the serial interface with /dev/ttyACMx. Have you tried to debug the kernel to see what is happening in the kernel side?

    The Processor SDK which has kernel v4.1.18 was released in 2015, and no longer supported by TI, so to get TI support, please try to replace with the latest SDK v5.2 kernel to reproduce the issue.

    First you can try to disable MUSB CPPI DMA in kernel config to see if the issue still happens in the current v4.1.18 kernel you use.
  • 0 in reply to Bin Liu
    Prodigy 160 points

    I guess the same issue has been seen on units with the updated OS.  I've heard second hand there is a problem caused by the number of devices and the limited number of interrupts available on the processor. Thanks for your help!

  • 0 in reply to Brandon Edmonds74
    TI__Guru**** 175031 points

    Hi Brandon,

    Brandon Edmonds74 said:
    I guess the same issue has been seen on units with the updated OS.  I've heard second hand there is a problem caused by the number of devices and the limited number of interrupts available on the processor. Thanks for your help!

    I am not sure I fully understand your message. Does it mean you have found the root cause and solved the issue? or you are still seeking support from TI?

  • 0 in reply to Brandon Edmonds74
    TI__Guru**** 175031 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.