Jetson nano EVK UART /dev/ttyTHS1 goes into oscillation (40Mhz) when connected to USB-FTDI cable

[arnout.diels]

Hi,

I am, quite simply, trying to hook up an FTDI USB-to-UART (3v3) cable to my jetson nano EVK on the /dev/ttyTHS1 port. (L4T r32.5.0)

To reproduce:

• Only connect GND + TX pin (pin 8 of the EVK) to the FTDI-UART cable. (The RX works, and I am ignoring it for the purpose of this post, and just not connect it) Log in through ethernet cable on ssh, and disabled nvgetty, installed microcom, and control /dev/ttyTHS1 through “sudo microcom -p /dev/ttyTHS1 -s 115200”. On the PC, just open putty on the virtual serial port

• After I let the jetson send a single character, it goes into an oscillation on its TX pin.
• Once I disconnect the TX pin cable, the oscillation stops.
• If I send characters from the jetson without anything connected to the pin aside from the scope, all works perfectly
• If I put a 500 ohm series resistor on the line, everything still works
• If I only put a 130 ohm resistor in series, the TX line goes into oscillation
  (FYI, tested this with 2 different common FTDI-UART 3v3 cables)

• If I simply connect 130 ohms resistor to the TX line to ground, the line goes into immediate oscillation as well.
• Same with 500 ohms to ground (cant source 10mA) without going into oscillation
• Same with 1k to ground (cant source 3mA) without going into oscillation
• 5k to ground was ok. No oscillation. (it can source 660 uA)

Some images:

TX pin of jetson without anything connected:

TX pin with 500 ohm series resistor to FTDI connector:

TX pin with 130 ohm in series => starts oscillation

So, I would guess for some reason the FTDI cable is sinking too much current, which then somehow causes the jetson uart block to go into oscillation (and never recover)…

I did not bother to check the datasheet for max current sourcing on that pin, because… it’s just uart, and you’d expect it to work with such a default cable. But apparently not. (I thought I’d make this post in case some else ran into the same issue). Also, the fact that it goes into oscillation… indefinitely seriously threw me off track…

Now that I looked at the datasheet, I don’t immediately find the maximum drive strength of pins. Google tells me the drive strength is configurable though the device-tree, but I dont directly find what the range is exactly. Can somebody perhaps enlighten me on this?

Thanks for your feedback

[arnout.diels]

Btw, drive strength of the nano is not relevant, since on the EVK there seems to be a level shifter anyway for those pins. (TXB0108RGYR if I am reading the correct schematics).

I am guessing this is the one to blame (or its choice on the EVK for these pins)…

[linuxdev]

I can’t answer, but some possibilities:

• Perhaps grounding the unusued pin through a small capacitor, e.g., 0.01 uF, would stop oscillation and show it is A.C. noise.
• If you can measure with the oscilloscope at the 1.8V side of the level convertor, perhaps it is the level converter itself at issue. It might be interesting, if you have a 1.8V cable, to see if the issue exists without the level converter.

What is your use-case for this?

[JerryChang]

hello arnout.diels,

there’s level shifter, please see-also application note of 40-Pin Expansion Header GPIO Usage Considerations.

[arnout.diels]

Hi,

@linuxdev, there is definitely the level shifter in between, but I now also measured it at the nano side (see picture) and interestingly, the ocillation is there too. If I hold the probe steady, and not have any load connected while sending some characters, I can see the correct UART waveform. If I connect the load, and send one character, I get the oscillation again.

My initial thought was that this would solely come from the levelshifter itself. But as @jerryChang also pointed, the level shifter is bidirectional, and as everyone that has ever worked with them knows, they are evil :). If the load is a little too big, it “thinks” the other side starts driving, and reverses the driving path. Then the nano drives stronger, causing it to swap directions again. This most likely causes the oscillation. Anyway, the application note describes in detail how to connect it properly, but, just letting you know this is NOT obvious when just connecting a simple UART cable to it!

Anyway, my usecase is simply to connect the nano module UART pins to some other custom hardware. But I’m sure will be able to work around it. However, just because this behavior is pretty unexpected, I thought I’d document it here.