Hi,
I tested my uart code on Jetson TX2 that it works fine, but I tested on Jetson Nano, it
can't be normal. I found Jetson nano tx pin only output 1.8v, but Jetson Tx2 is about 3.0v.
Why does Jetson nano UART1_TXD (J41 Pin8) only have 1.8V output?
Is there a problem with my Jetson nano development board?
Regards,
Locar
Sorry to correct the Jetson nano uart signal information
UART1_TX should be in same 3.3v level to UART1_RX as both pass through a 1.8v to 3.3v level shift. Please check their level without device, if it is still 1.8v, there might be problem on level shift.
Hi Trumany,
Thank you for your information.
I tested Jetson Nano A02 and B01 Developer kit, they are both same.
If I do not connect the device(RX), the tx voltage could be dropped to zero.
But I tested my use console on Jetson TX2, it works fine even if I connected the device(RX).
Why does Jetson Nano be not working?
Regards,
Locar
I tested Device A/B/C on Jetson Tx2, they can work normally.
But I tested Device A/B/C on Jetson Nano, only device C can work normally.
I don’t know why Jetson Nano has poor compatibility, but now it works with the device C, thanks.
Regards,
Locar
It’s strange… the voltage of RX are all correct at 3.3v, while as you can see, only device C made the voltage level of TX to 3.3v correctly. I have no idea what kind of compatible problem will cause the 3.3v to 1.8v as that in waveform of device A & B… Is there any clue in their data sheet? Can you please share the name/part number of device A, B & C?
Hi Trumany,
Device A is below USB to UART board, you can buy it to test on Jetson Nano.
Device C is as below,
Regards,
Locar
Note that the module itself tends to have 1.8V levels (not all, so be careful, this is a “general” statement). References to pins on the carrier board usually say 3.3V because of a level converter. For the development kit carrier board J24 can optionally be set to either 1.8V or 3.3V for some of the I/O, with the default position being 3.3V.
UARTs from the carrier tend to all be 3.3V, and although they will probably tolerate 5V I would not expect this to function.
Many USB serial UARTs provide the serial UART pins plus the 5V power made available to USB devices. That 5V is not used since the UART on the Jetson side is already powered. In cases where there is a 5V pin just ignore it…but if it says the I/O level is anything other than 3.3V, then you probably need a different UART.
Hi linuxdev,
Thanks for your information.
Yes, I have checked Jetson nano datasheet as below
, so I set Voltage switch to 3.3V before connecting.
I connected it to J50(UART2), the TX is fine, I could see
the system log after power on, but when I connected it
to J41(UART1) to develop, but TX could not work.
Regards,
Locar
Hi, the output voltage of level shift depends on Rpu too, the Rpu on TX (rx of device) will cause different Vol. UART2 on J50 pass thru a different level shift which has no such request.
Hi Trumany,
Thanks for your information.
I don't know why J50 has "no such request" but J41 does.
Do you have J41 Tx and J50 Tx output current spec?
Regards,
Locar
The level shift of UART2 on J50 is TXB0302 which needs Rpu > 20 Kohm, the one to J41 is TXB0108 which needs Rpu > 50 Kohm. You can get their datasheet by searching online. The problem is if the Rpu on your UART device fit the request.
Also be careful to not use the UART set up as serial console unless you’ve disabled serial console. Any activity on that serial console within U-Boot would cause boot to halt while waiting for input.
Hi Trumany,
Thank you for your information.
Yes, we also checked this spec, the Rpu of J41 should be higher than that of
J50 more. I am worried that maybe many UART console boards will not work
properly on J41 due to we should concern about Rpu >50Kohm.
Regards,
Locar
Hi linuxdev,
Thank you for your reminder.
I understand.
Regards,
Locar
@Trumany I just came across this thread because I am having the same problem as @locar_chang - I am connecting a device (Impinj RS1000 RFID module) via UART (J41 / ttyTHS1) to my nano. The RX on the nano is working - I can read data from the RS1000 just fine - it operates at 3.3v. However, TX is not working - the RS1000 won’t receive any data from the nano. I don’t have an oscilloscope handy to confirm it is in fact putting out <1.8v, but I have a strong suspicion this is the issue. I noticed that the Rpu of the UART interface on the RS1000 device is min/typ/max 25/40/55 Kohm (see p.11 of the attached spec), so I’m wondering if the typical “40” is not sufficient? If so do I need to put additional resistance in series on the nano’s TX line for this to work?
I looked at the spec sheet from your URL, and unfortunately it seems the PDF is all a non-searchable graphic image, rather than being text plus images. From what I could tell the spec never mentioned a specific voltage level for the UART, and instead talked about dBm. The original RS-232 DB-9 connector was intended to work over a large range of voltages, and perhaps it was designed with that in mind. The UART of the Nano should be specifically 3.3V and I don’t know how to verify that for your chip without an oscilloscope.
Also, make sure when looking at “ls -l /dev/ttyTHS1”, that the “group” is “dialout” and not “tty”. If the group is “tty”, then this is being used for serial console. If the group is “dialout”, then the tty will be available for general use.
Due to J41 RX is working, I think ttyTHS1 should be correct.
But I found J41 Tx has a poor drive to cause this issue, I added an OR gate(74LVC2G32) as a level shiter buffer to solve this issue.
Before, the voltage could only be dropped about 1.8v by J41 Tx, so the console board could not detect 1 value.
After, J41 Tx could dropped voltage to about 3.3V.
For your reference…
It sounds like you got it working, but I’m not sure. Did the buffering (which got voltage to 3.3V) result in a “fix”? If previous drive strength dropped to 1.8V, then I would not be surprised if something as simple as a buffer would solve the problem.
Yes, it is currently working after applied OR Gate solution, this is a development board compatibility issue, not a firmware issue.