Hi
my uart have some problem. It just can receive cannot transmit. My system is jetpack4.6.2 ubuntu18.04. When I use jetpack4.3 Ubuntu 16.02 the uart(ttyTHS0) is working good. So I find devmem2 and make some change.
Sudo devmem2 0x024300a0 word 0x00000458
Sudo devmem2 0x024300a8 word 0x00000434
And I notice that my TTL-USB board’s receiving light is bright. So I think it must be something wrong of my Xavier’s uart TX_D pinmux settings.
However, even though I change the pinmux. It doesn’t work. So I find the dtb file. I want to confirm what happened in the Xavier. But I don’t know how to change it.
Before continuing, are you certain that flow control is not enabled at one end? The UARTs at each end run blindly without knowing the setting at the other end. If one side thinks there is flow control, but the other does not, then half of the communications will disappear.
Loopback is an interesting way to diagnose such problems. This is just directly wiring a UART’s TX and RX together so it “talks to itself”. UARTs are wonderful in agreeing with their own settings (although it is actually possible for a TX and RX to differ, but you would have to try to do this). If flow control is enabled, then also CTS and RTS must be wired together. Then you simply use a serial console program (I prefer gtkterm, “sudo apt-get install gtkterm”, but others like minicom or PuTTY will work) to connect to that device. Anything you type in will echo back if it works.
An example gtkterm to have a device talk to itself (adjust parameters if they differ for you): gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyTHS0
If this works, and if you have an oscilloscope, then I’d verify if CTS/RTS changes when one end sends (and if not connected, then this is a sign that connecting them would cause this to work if both ends enable this…if not, then there would be a device tree edit to fix such that CTS/RTS would work).
Thanks， I tested uart with minicom and set the current control to none, but there is still no parameter.
I measured the voltage value at the TX terminal with a voltmeter and found that it was always 3.3v. Is this high level causing no transmission? How should I set this
3.3V is correct as a high level, but if you measure this with a voltmeter it probably won’t be a valid answer since data only flows in short bit changes. If this was an oscilloscope, and you saw only 3.3V DC, then it is proof that there was no TX. However, that isn’t the real question. The real question is if the end not transmitting over TX was told that it was not time to transmit. This can occur if CTS/RTS flow control is enabled, but the wires are not connected. When flow control is enabled the Request To Send will be triggered if data is ready to send, but actual send will not occur until the other end says Clear To Send. This is a software setting, and neither end knows what the other end thinks the settings are…they blindly assume each end has the same settings (thus loopback is good, but if CTS/RTS is on, then and not connected in loopback, then having that setting will stop even a loopback from talking to itself).
Was this test with loopback?
Did loopback also have CTS and RTS tied together?
Was the 3.3V test via oscilloscope?
Note that it is true that if more data is flowing, then the DC voltage would appear to start dropping some for a voltmeter, but it would depend on capacitance and the voltmeter design whether any voltage drop would be visible.
It is also possible that the mentioned PINMUX could need changes, but the others should be checked first. Also, the PINMUX applies to the dev kit carrier board. If you have a third party carrier board, then the PINMUX itself would need other modifications (the device tree generated is the actual part being edited, the PINMUX is just a tool to generate the device tree).
Hello, I tested nvidia and confirmed that the loopback experiment can be successful. The flow control is set to none, and the cts and rts are not involved. They are all set to none. Maybe there is no problem with nvidia itself. In addition, I connect an oscilloscope to test that nvidia’s tx can also receive signals. But after I connected the TTL-USB test board, I measured the voltage of the board with an oscilloscope and found that the voltage could not be pulled down. The oscilloscope always displayed 3.3 V. Is this problem related to the Jetpack version? Previously, I used Jetpack 4.3 ubuntu16 to send and receive data through serial ports. This time, I used Jetpack 4.6 ubuntu18 to transmit data.
In addition, the board level changes slowly
It looks very skewed. Often that is a sign of very bad impedance matching. Some pads of the SoC do have programmable skew, but I believe the UART does not. Even if it did, then that is probably far from normal. My thought is that the load being used changes the impedance too much. A very common problem would be one of:
The hardware connected to the Jetson is not 3.3 V, e.g., perhaps it is 1.8V specification.
Long cables (and often, with significant length, one needs TX and RX to be twisted pair, and ground to be with shielding).
Note that the above applies with a discrete external USB UART as well, but voltages might purposely (and correctly) be other than 3.3 V. If this is testing a USB UART from the USB port, then the Jetson has no control over that.
Are you positive that the other end of the UART is specified at 3.3 V signal levels? Are the cables particularly long, or are you in an extremely noisy (electrical/EM) environment?
Hello, I set 3.3v of UARt. When I use the oscilloscope to measure the loopback experiment, it is found that the transmission can be normal, but when I suspend the TX measurement, the above situation will occur
The only signal which will matter is when TX and RX are connected, e.g., in loopback, or else to another UART. The top image has a very poor trailing edge to the signal. Can you confirm that this was with TX and RX properly connected, but software was told to stop transmitting? If so, then something is wrong. If indeed it is wrong, and although it is not normal, does that odd signal show up when no data is transferring and RX and TX are disconnected? If disconnected and it does this, is the origin of the signal from the TX, from the RX, or both?
Thanks. I found the problem. My TX pull-down resistor is broken. So when I tie TX and RX together they can communicate. Because TX can use pull-down resistor of RX.
