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:
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?
FYI, the default baudrate is 115200/8n1.
may I know which pin you’d connected to for gathering serial data.
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
$23=0 (h⸮[+K⸮⸮⸮ٕ⸮с⸮⸮k:0000000⸮⸮CS⸮⸮⸮r⸮⸮⸮B⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮Y mm/min)
The same setup on a Jetson Xavier NX results with a coherent serial data stream
Here is a photo of my wiring;
Seems like a similar problem is discussed here
could you please have a try to Disable Console over UART of the Nano platform.
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.
it’ll save to your local machine if you’re install the JetPack release image with SDKManger.
there’s default path,
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?
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 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?
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:
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;
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?
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.
may I know the results,
were you able to modify board configuration files and re-flash the board for checking?
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
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
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?
I just did another experiment.
I removed all the properties from line 147 in the
p3448-0000.conf.common file so now it reads:
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.
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:
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 ("
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).
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.
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.
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.