I am creating this post primarily to inquire if there will be an official firmware release/update to fix the issue described in: Reading serial works on first run ONLY?
For more context, we have a hardware component (in a robot) with firmware that talks serial communication to the AGX Orin over the USB port; specifically, the USB ACM (/dev/ttyACM0) device. The serial communication works fine the first time; however, restarting the serial communication fails. It appears that the failure is caused by the USB ACM device failing to properly “close”; therefore, preventing it from properly re-initializing the next time.
The workaround provided in Power down USB ports - #4 by vsaw works by manually power down and up the USB port. Unfortunately, it’s unfavourable to trigger this behaviour each time the robot firmware needs to be restarted. Based on this, it would be ideal if this could be fixed in the AGX Orin. I have also tested this on the Xavier NX and this problem with USB ACM does not occur.
Hi,
We would like to check it further but do not have a way to replicate the issue. Could you check if it is possible to reproduce it on Orin developer kit and share us the steps? So that we can set up and give it a try. Would be great if you can help on this. Thanks.
Unfortunately I think the only/best way to reproduce the issue is to actually get physical hardware, including a device that talks serial over a USB cable to the AGX Orin. I believe the simplest setup would be using an Arduino to reproduce this issue, similar to the setup in: Reading serial works on first run ONLY.
Is this a feasible path for you and your team? If so, I can provide more detailed instructions on how to reproduce the issue. Thanks.
[quote=“jyang2, post:1, topic:238686”]
Reading serial works on first run ONLY
[/quote] 2 month ago and that thread was closed.
The issue can be replicated with a variety of USB serial devices and I suggest any Arduino would be the easiest way. It appears to me that any device mounting as /dev/ttyACMx exhibits this issue.
For now I found scrappy workarounds but I’d love to hear if this is something that will be potentially fixed in the future.
I have multiple MCUs connected via USB.
One workraound for now is to have one MCU connected to the USB-C port which does not seem to have this issue. However it exhibits the same issue when I use a hub on that port.
Another MCU is connected to the USB-A and as a workaround I created a separate program that handles the communication with this device and that program stays always on.