Yes, I’ve seen the same as well, and not just in that one case. I do not remember details, but much of this seems to have been from a change in device tree disabling flow control. The earliest TX1s could even use flow control on serial console, and then it stopped working, timed with a device tree change.
Unfortunately I do not remember what the device tree change was, but if you didn’t need flow control, then that lack of flow control would never be noticed. I don’t think it was the carrier board causing flow control issues, although there may have been a device tree change coincidentally at fault.
Although flow control can help with some data issues (at start/stop of flow) I doubt it would be related to large scale data corruption. Mostly wanting to know how different bit patterns might or might not cycle with good/bad data streams is to answer that question: Whether the corruption and be tied to particular moments of start/stop, or to show a truly random versus cycling corruption.
Hey, in my case the data seems to be scrambled quite randomly, there seems to be no pattern see some examples here:
I don’t think it’s a noise issue either as the actual device I’m using is a “shield”, which sits directly on the GPIO pins, no wires invoveled. The arduino setup is just for a sanity check.
The same setup on a raspberry Pi and the Jetson Xavier NX works well and the data goes both ways unscrambled. Actually, for some reason on the Xavier the TX stopped working last week. But thats for a different thread.
Serial Device : /dev/ttyTHS1
B - Lockfile Location : /var/lock
C - Callin Program :
D - Callout Program :
E - Bps/Par/Bits : 115200 8N1
F - Hardware Flow Control : No
G - Software Flow Control : No
Just did another experiment, powered the Arduino/GRBL board via the GPIO pins while connecting the TX/RX via a USB-Serial-FTDI adapter to the Jetson.
Data goes both ways perfectly. See pictures below.