GPIO UART serial communication scrambled data

yurikleb · October 21, 2020, 5:11am

I’m trying to communicate with a GRBL CNC Control Board via the GPIO Pins.

I managed to establish communication on a Jetson Xavier NX, via the /dev/ttyTHS0 port, after disabling nvgetty:

$ systemctl stop nvgetty
$ systemctl disable nvgetty
$ udevadm trigger
$ sudo reboot now

Unfortunately, I’m unable to re-create the same setup on the Jetson Nano.
On the Nano, after disabling nvgetty, I am able to connect to the CNC-Board via the /dev/ttyTHS1 port. However, the data that comes thru is scrambled, for example:

⸮⸮⸮K⸮⸮⸮⸮⸮u5)⸮
Grbl 1⸮⸮⸮⸮K⸮⸮⸮⸮⸮u5)⸮

I tired different baud-rates (the board works very well with the Xavier and a Raspberry pi on 115200 baud, as GRBL 1.1 is set to work over this baud rate)

I also noticed the Nano has
serial-getty@ttyGS0.service - Serial Getty on ttyGS0
Which I’m unable to fully disable (it restarts after a reboot).
Could it be interfering with the communication on ttyTHS1?

What else could be the cause for the serial data scrambling?

JerryChang · October 21, 2020, 9:03am

hello yurikleb,

FYI, the default baudrate is 115200/8n1.
may I know which pin you’d connected to for gathering serial data.
thanks

yurikleb · October 21, 2020, 10:44am

Hello Jerry,

I can confirm the baud-rate setting in minicom is 115200/8n1.
I just did another experiment with an Arduino Uno flashed with GRBL on it.

When connected via USB to the Jetson Nano, it shows up on /dev/ttyACM0
and the serial communication (via minicom and the Arduino IDE serial monitor) works well.
Here is a sample of an incoming data stream from the Arduino (GRBL Settings):

Grbl 0.9j ['$' for help]                                                     
['$H'|'$X' to unlock]                                                        
$0=10 (step pulse, usec)                
$1=25 (step idle delay, msec)           
$2=0 (step port invert mask:00000000)   
$3=1 (dir port invert mask:00000001)    
...

However when I connect the Arduino to the TX/RX pins of the Jetson Nano:
Pin 6 for ground and pins 8,10 for the UART the Arduino appears on port /dev/ttyTHS1 and the incoming data is corrupt:

Grbl 0.9⸮⸮⸮⸮⸮⸮K⸮⸮⸮⸮⸮u5)mH'|'$X' t⸮⸮]⸮⸮kk⸮դ⸮$0=10 (st⸮⸮⸮[⸮	͕⸮⸮ (step i[X^KH[⸮֩H⸮I⸮B⸮ѕ⸮⸮⸮⸮⸮vert mask⸮⸮⸮JC!⸮S⸮B"⸮Ɂ⸮⸮⸮ѥ⸮⸮ert mask:LJC!S⸮B⸮ѕ⸮⸮⸮⸮⸮⸮⸮⸮nvert, bJC!RS⸮Bb⸮⸮⸮с⸮⸮⸮́⸮vert, bo⸮S⸮B⸮ɽ⸮⸮⸮⸮⸮⸮⸮⸮vert, boo⸮CS⸮B⸮х⸮⸮́ɕ⸮⸮⸮t mask:00⸮⸮⸮LLJCS⸮r⸮⸮⸮BRչ⸮ѥ⸮⸮⸮⸮⸮iation, mS⸮r⸮⸮⸮B
ɍ⸮ѽ⸮⸮Ʌ⸮⸮, mm)
$1⸮⸮⸮\Kс⸮⸮⸮⸮⸮ͱool)
$20⸮⸮⸮⸮ˋ⸮⸮⸮⸮⸮⸮ͱ⸮ol)
$21=⸮⸮⸮+⸮+ͱ⸮⸮⸮⸮⸮⸮22=1 (hom⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
$23=0 (h⸮[+K⸮⸮⸮ٕ⸮с⸮⸮k:0000000⸮⸮CS⸮⸮⸮r⸮⸮⸮B⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮Y mm/min)
MOML⸮⸮BB⸮⸮⸮⸮⸮⸮͕⸮⸮Q mm/min)
⸮⸮	⸮+⸮⸮⸮չ⸮⸮⸮͕⸮
...

The same setup on a Jetson Xavier NX results with a coherent serial data stream

Here is a photo of my wiring;

yurikleb · October 21, 2020, 10:46am

Seems like a similar problem is discussed here

JerryChang · October 22, 2020, 5:48am

hello yurikleb,

could you please have a try to Disable Console over UART of the Nano platform.
thanks

yurikleb · October 22, 2020, 6:21am

Hey Jerry, where can I find the p3448-0000.conf file? to remove the specification console=ttyS0
Does it mean I need to re-build the kernel?
I’m sorry I’m new to the Jetson platform.
Thanks!

JerryChang · October 22, 2020, 12:43pm

hello yurikleb,

it’ll save to your local machine if you’re install the JetPack release image with SDKManger.
there’s default path,
for example,
~/nvidia/nvidia_sdk/JetPack_4.4_Linux_JETSON_NANO_DEVKIT/Linux_for_Tegra/

yurikleb · October 23, 2020, 3:50am

Hey @JerryChang.

I’m slightly confused about the SDK manager.
When downloading the SDK Manager from this page I’m getting an AMD64.deb file which I’m unable to run on the NVIDIA Jetson Nano kit as its arm64 based.

Origainnaly, I used the “SD card method” as described here. Do I still need to install the SDK Manager and reinstall Jetpack somehow?

JerryChang · October 23, 2020, 5:45am

hello yurikleb,

please refer to NVIDIA SDK Manager page for [System Requirements].
you’ll need a host machine to install JetPack release via SDKManager.

SD card image did not contain the board configuration files, i.e. p3448-0000.conf
please also download the image to your local machine for that.
thanks

yurikleb · October 26, 2020, 11:05am

Hey Jerry,
Thanks for your help, and sorry for all the confusing questions.

I have installed Ubuntu 18 on a Host machine and the SDK manager.
I’m now downloading the software as described here in step 3.2.

At which step and on which machine should I update the p3448-0000.conf file?

On the Host Machine before the flashing? Should I look for this file in the download folder after all the downloads are complete?
Or on the Jetson Developer Board after the flashing?

yurikleb · October 26, 2020, 12:32pm

Hello Jerry,
I finished downloading the all the files required via the SDK manager.
In step 2 (Details and License) I clicked the “Download Now, Install Later” checkbox.
After the download was complete I found the p3448-0000.conf.common file on the Host machine in the folder which I set as the download destination:
/media/designlab/Stuff/nvidia_sdk/JetPack_4.4.1_Linux_JETSON_NANO_DEVKIT/Linux_for_Tegra/
folder.

I updated line 147 to:
CMDLINE_ADD="115200n8 console=tty0 fbcon=map:0 net.ifnames=0";

I re-launched the SDK Manager, however In step 3 > Target Components, when the “Jetson OS image > Creating OS Image” reaching 99.9% it fails.

Here are some screenshots;

yurikleb · October 27, 2020, 1:26am

Hey Jerry,
I managed to get past the errors by setting up a new Ubuntu 18 machine.
However I’m still not sure at which point of the process I need to update the setting in the p3448-0000.conf.common file?

The SDK Manager seem to jump automatically from the download phase to creating the Jetson OS image. It only stops to ask me for the username and password for the Jetson before flashing, Which I guess is to late to update the p3448-0000.conf.common file as it’s already applied to the OS-Image file?

Also, should I only remove the console=ttyS0 setting or the entire line:
CMDLINE_ADD="console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0";

Whats would be the right way to do it?

Thank you!

JerryChang · October 27, 2020, 2:56am

hello yurikleb,

SDKManager download and install default JetPack release to your local host machine.
for the development,
you may have modifications to the configuration files, please enable flash.sh to flash the image instead via SDKManager.
please also check Flashing and Booting the Target Device chapter for more details.
thanks

JerryChang · October 30, 2020, 2:19am

hello yurikleb,

may I know the results,
were you able to modify board configuration files and re-flash the board for checking?
thanks

yurikleb · October 30, 2020, 5:29am

Hello Jerry,

Those are my steps so far:

1st I selected “Download now Install later” in “step 2” in the SDK manager. but it only downloaded lots of .deb files to my /home/user/Downloads/nvidia_sdk_downloads folder
Trying again I didn’t select “Download now Install later” in Step 2, and the SDK Manager just asked me for the username and password of the board and then flashed everything automatically to the Jetson.
I was able to locate the ~/nvidia/nvidia_sdk/JetPack_4.4.1_Linux_JETSON_NANO_DEVKIT/Linux_for_Tegra folder only after the SDK manager finished flashing my Jetso automatically.
I updated line 147 in the p3448-0000.conf.common file to read: CMDLINE_ADD="115200n8 console=tty0 fbcon=map:0 net.ifnames=0";
I put a jumper on the Force Recovery and GND pins on the Jetson Nano Dev Kit
I ran a sudo ./flash.sh jetson-nano-devkit mmcblk0p1 command
Flashing seemed to be successful, I removed the Jumper and went thru the initial Ubuntu config process on the Jetson
I disabled nvgetty service and installed minicom
I connected my board, configured minicom to work on /dev/ttyTHS1 port
I can send and rescieve data from the board but it still looks scrambled as before

Is there any way to check the settings in p3448-0000.conf.common were actually applied to the flashed image?

yurikleb · October 30, 2020, 6:14am

Hello Jerry,

I just did another experiment.

I removed all the properties from line 147 in the p3448-0000.conf.common file so now it reads: CMDLINE_ADD="";

I ran the flash.sh again, went thru the initial Ubuntu config process on the Jetson, disabled nvgetty, installed and configured minicom,

Unfortunately the data is still scrambled.

linuxdev · October 30, 2020, 6:33pm

Noise could be causing randomness, but if instead it is a bit shift, then it might show up with the sending of a specific pattern. For reference, here is an ASCII table:
https://www.ascii-code.com/

Notice that the letter “space” is 00100000. If this bit shifts, then you might see a “@” or a “€” (assuming your character set shows that character). Similarly, the character capital U (“U”) is 01010101, which is its own repeating pattern, and if this were to bit shift without truncating (I should probably just call it a rotate), then it would alternate with “ª”. Truncating, or truncating with rotation, would offer a different pattern.

So on your terminal or application try sending a block of just space characters, or a block of text which is entirely “€”, or a block which is entirely just capital U “U”. See if a pattern shows up or if it is random. Patterns tend to be a software setting issue, while randomness is noise or perhaps voltage levels being marginal (which turns into noise).

Honey_Patouceul · October 30, 2020, 7:15pm

Just my 3 cents question: Wouldn’t it just be a control flow issue (since some chars are also correctly read) ?
Someone from NVIDIA may tell what is the control flow used (HW, SW or none) for this uart, or you may try each one from your serial terminal settings.

linuxdev · October 31, 2020, 5:16pm

Flow control issues usually leaves one direction working, with the other direction completely stopped (just TX or just RX would work in the case of mismatched flow control). If each end has a different stop bit setting, then both ends receive the character offset wrong by 1 bit, and then it cycles through enough bits to self-correct, and aligns correctly, showing a correct bit (cycling through wrong bytes and occasional correct byte in a repeating pattern). Noise is usually a random bit flip on an otherwise “the rest of the bits correct” character (everything can scramble). I do think HW flow control aids the UART in correct stopping/starting at higher speeds when SW flow control would no longer stop buffer overflow/underflow, but I don’t think of it as something causing bit flips.

The above is one reason I really like loopback tests. A single UART will never disagree with itself. Any failure becomes much more interesting.

Honey_Patouceul · October 31, 2020, 5:50pm

Probably you’re correct. I was asking this because I’ve only had a Nano for 24 hours, it was with old devkit A02 and faced similar symptoms on J44. At that time, one user reported improvement using a serial adapter with HW flow control. I have returned the Nano before being able to further test, never know what was the correct control flow setting and was unaware of the nvgetty issue at that time, so…

From the pictures above, this case is using B01 devkit, so this might be unrelated.
Might indeed be worth checking levels on both ends.