Does anyone have any suggestions for level shifters?

My new Nano has arrived, but the situation is still not optimistic. This time sending data seems to be okay, but receiving fails.

I connected the wires refer to the wiring diagram below and connected Nano to Arduino.A side is Nano and B side is Arduino

The Arduino program is the same as before, returning the received data.The result is shown in the figure, and Nano is stuck and cannot exit minicom.
nano uart接收2

Then I connected the Nano to the laptop via a UART to USB converter.
Nano sends data smoothly:
nano laptop发 minicom
But for receiving, only a few data can be received occasionally. The part underlined in red is the data sent to nano via laptop:

Same result for the program I wrote:


The red underlined is the data sent by Nano. But Nano cannot accept data.

Can you use oscilloscope to probe the signals? That will be helpful to understand what’s going on.

My tutor will be back next week. I can’t find an oscilloscope before that. I will reply to you again,after I measure the waveform of signal.

By the way, for the sending problem, I can observe the signal of TX. Which pin should I observe when there is a problem with reception?If I want to observe the RX pin, should I connect the RX of Nano to the TX of the Arduino, and observe the signal when communicating?

You should confirm the TX signals are correct and the RX signals are what you expect.

I am using this level shifter (for i2c) to connect a 5 V ADC to 3.3 V Jetson Nano, see photo.


or:
https://joy-it.net/de/products/COM-KY051VT
The ranges are
VCCa: 1.2 - 3.6 V
VCCb: 1.7 - 5.5 V

The I2C level shifters have two problems:

  1. They are generally not very fast – I2C generally tops out at 400 kHz.
  2. They assume that there are pull-ups on both sides of the shifter, to each of the appropriate rails.

The problem with 2) is that the rise time of your communications signal will be determined by the pull-up strength, and how far towards zero you can pull the signal depends on the performance of the open-drain MOSFET in the converter. For slow UART rates (9600, 19200, etc) it will probably work fine; probably even with 57600 speed. I wouldn’t expect robust connections at higher baud rates, like 1 Mbps, using a I2C-based translator.

OK, I take only about 15 values per second from the magnetometer (vs GPS, see image). I habe not connected pull up resistors. I think, the ADC has pull ups.

As in my case you can also connect UART via USB.

import serial

ser = serial.Serial("/dev/ttyACM0", 9600)
connection via USB, my case

#ser = serial.Serial("/dev/ttyTHS1", 9600)
connection via the pins

#ser = serial.Serial("/dev/ttyUSB0",9600,8)
USB Adapter, for example

You can use a oscilloscope to check the I2C signals quality. The stronger pull-up and better ground connection will be helpful if signals are not so good.

Sorry to reply you so late. This morning I tested the waveform with my tutor. We think there is a problem with the hardware.

Test based on the UART communication between Jetson and M16C. Through the pull-up, M16C is connected to Jetson at 3.3v level. The wiring is as follows:


The result is neither sending nor receiving.

For sending, the interesting thing is that it can be sent normally if it is not grounded. But when the ground wire is connected, Jetson’s level drops from 3.3v to 1.6v.

Then test the tx pins (connect directly to the oscilloscope):


When not grounding or directly connecting the GND of the probe to the GND of Jetson, the waveform is normal.
However, if the GND of Jetson is extended with a wire and connected to the GND of the probe, the waveform is as follows:

I picked a good waveform, and you can see that its level has dropped from 3.3v to 1.8v. Sometimes it will have multiple drops.

If you connect the GND of Jetson and M16C and Jetson send data, the waveform is as follows:


The level value is directly droped from 3.3v to 1.6v.

For receiving, whether it is connected to M16C, Arduino or Laptop, there are a lot of packet loss, and the waveform at the sending end is normal.

Then I also tested connecting the Arduino to Jetson via a USB to UART converter, but it still couldn’t receive normally and a lot of packets were lost.

Are you testing with usb to UART bridge device? It is different to UART2 as you previous said.

Anyway, the UART ports of Jetson are validated before ship out, so please check your external devices setting including wires connection, power rail level etc.

I did test with usb to UART bridge device. But I had already gone home at that time, so there was no waveform. When connected to Jetson, its device node is ttyUSB0.

When Jetson connecting to M16C, a pull-up resistor is added to the TX (M16C) pin to make it directly connected to Jetson at the 3.3v level. No communication when the ground is shared. If the ground is not shared, Jetson can send normally but not receive. If Jetson sends data in common ground, the level will drop from 3.3v to 1.6v.

What I can’t understand the most is that when the GND of Jetson is connected to the GND of the probe through a wire (without other device connected), it will produce a level drop. Without grounding, or directly connected to Jetson without wire, there will be no level drop. What is the difference between the two? The wires I used are as follows:
wire

Is there any other serial port that can be used besides UART2? I noticed that j50 provides a set of UART interfaces, but I can’t find more information, such as how high its level is. The school’s laboratory is still closed. I can only enter with my tutor, he will test with me next Monday.

As previously said, the voltage level is 3.3V, you can choose other UART port to test. Please check the OEM DG and reference schematic in DLC to select the port.

Not sure about the GND problem you mentioned, in general, if suspect the ground connection, a stronger connection is suggested, to use more wires/pins or select other ground pins.

Do you know about the device node of the UART on J50? I can only find two devices nodes of serial port:
捕获
But none of them match the UART on j50.

Hi,

J50 -> UART2 on module -> UART1 on chip

According to the dmesg, UART1 is 70006000.serial so mapping to ttyS0.

[ 1.067582] 70006000.serial: ttyS0 at MMIO 0x70006000 (irq = 63, base_baud = 25500000) is a Tegra
[ 1.069127] 70006040.serial: ttyTHS1 at MMIO 0x70006040 (irq = 64, base_baud = 0) is a TEGRA_UART
[ 1.069554] serial-tegra 70006200.serial: RX in PIO mode
[ 1.069649] 70006200.serial: ttyTHS2 at MMIO 0x70006200 (irq = 65, base_baud = 0) is a TEGRA_UART

Thank you for your reply! This is very helpful! I will test this tomorrow and hope for good results.

Hi,
unfortunately, the UART test results on J50 are consistent with on J41. Is it possible that I just bought a bad product?I bought it on the NVIDIA Online Store: