GPIO UART serial communication scrambled data

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?

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

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?

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;

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!

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

hello yurikleb,

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

Hello Jerry,

Those are my steps so far:

  1. 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

  2. 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.

  3. 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.

  4. I updated line 147 in the p3448-0000.conf.common file to read: CMDLINE_ADD="115200n8 console=tty0 fbcon=map:0 net.ifnames=0";

  5. I put a jumper on the Force Recovery and GND pins on the Jetson Nano Dev Kit

  6. I ran a sudo ./flash.sh jetson-nano-devkit mmcblk0p1 command

  7. Flashing seemed to be successful, I removed the Jumper and went thru the initial Ubuntu config process on the Jetson

  8. I disabled nvgetty service and installed minicom

  9. I connected my board, configured minicom to work on /dev/ttyTHS1 port

  10. 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?

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.

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).

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.

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.

1 Like

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.

Hi yurikleb,
Did you check your minicom settings HW/SW Flow control, it should be disabled.

HW Flow Control was on.
I turned it off.

My current settings are:

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

However the data is still scrambled.

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.

Why can’t the GPIO TX/RX pins just work the same?


Replies on this topic: