UART0 on ttyS0 sends but isn't receiving any data

I have the problem that after booting I can see information of the boot process coming from the UART0 but at the end when the it asks me to log on I can’t send anything to it:

[  234.547811] CPU1: shutdown                                                   
[  234.605206] CPU2: shutdown                                                   
                                                                                
Ubuntu 18.04.2 LTS tx2-desktop ttyS0                                            
                                                                                
tx2-desktop login:

when I scroll up in the boot sequence I see the following lines:

[    0.904532] console [ttyS0] disabled                                         
[    0.904608] 3100000.serial: ttyS0 at MMIO 0x3100000 (irq = 36, base_baud = 2a
[    0.907061] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt  
[    0.907067] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt       
[    0.907456] pcieport 0000:00:03.0: Signaling PME through PCIe PME interrupt  
[    0.907460] pci 0000:02:00.0: Signaling PME through PCIe PME interrupt       
[    0.936614] tegradc 15210000.nvdisplay: probed                               
[    3.282414] console [ttyS0] enabled

So to me it seems as if the console is enabled and should work, so why can’t I send anything to it?

Is the RTS/CTS wiring connected? Or enabled in software? If so, make sure hardware flow control is disconnected and software not enabled. Also you should mention which release this is, if it is the dev carrier board, and if there have been any modifications to device tree or kernel. Can you also verify this is a 3.3V logic level UART you are using?

Hello Linuxdev,

thank you very much for your quick reply. You should forgive me since I’m very new at this kind of forum talk however I’ll try to provide as much information as possible.
So first of all this is the 4.9.140 kernel we are talking about, I downloaded the code from https://developer.nvidia.com/embedded/dlc/l4t-sources-32-1-JAX-TX2 and compiled it with the suggested linaro 7.3.1 toolchain.
The TX2 is mounted on a CTI Spacely carrier board on which I have connected the UART0_TX and UART_RX. I have also checked with a scope that the hardware is actually sending and receiving and this is the case so the signal is definitly going to the TX2 only it ignores it completely. I’m using a URS232A from Cytron on which I connected the wires as they should.
To make things very simple I have also Ubuntu 18.04 on my pc running and to test the connection I installed both on my pc and on the TX2 minicom so I could clearly see when I typed something on the TX2 minicom terminal I received it on my pc but the other way around didn’t work.

You talk about enabling the RTS/CTS in the software? Could you elaborate on this? Do you mean the software of in my case the minicom application?

So flow control can use the Clear-To-Send (CTS) or Request-To-Send (RTS) wires, but is needed only if your software (such as minicom) is told to do so. If one end enforces this, but the other doesn’t bother with it, then half of communications would disappear.

However, with a custom carrier board the issue might be that the port simply never got enabled. The device tree changes depending on carrier board, and is responsible for telling drivers a number of details about configuration of devices attached to the TX2 module. Different wiring, different device tree.

Think of the device tree as a way to pass arguments to drivers. If the driver is missing, or if it is the wrong version, then device tree is ignored or doesn’t do as expected. Change the hardware without changing the device tree, and once again hardware (such as serial ports) simply won’t work.

So prior to changing the kernel, did the port work? When you installed the kernel, what was your starting configuration from? For device tree, did you use the manufacturer’s (carrier board) board support package (which contains in part the device tree)?

Ok I understand, however saying that I’m using a custom kernel would be stretching the word a bit since I simply downloaded the code (without changing it) from your site (see my previous message) and I used the drivers from the Spacely carrier board that I found on the site of Connect Tech, they provide their custom flash script even so I believe I’m good there.
So I have no information about any prior working of the port since I had to start with this setup as I don’t have an other way of flashing or working with the tx2 in stead of being on the carrier board that I have. I have also contacted the manufacturer of the carrier board with the details of this issue that I have and I hope I get an answer as soon as you are giving me :-)

It sounds like you are saying you used the stock JetPack plus the carrier board’s board support package on top of that (which might include their kernel and device tree). This should be good to go if the BSP covers serial UART changes for the carrier.

I do not know anything about the changes this particular carrier board has, and so you’ll probably have to wait for their answer.

About the only thing I can offer is a suggestion to check with loopback. Normally one UART has to talk to another UART, and if settings differ between the two UARTs (or serial console program), then there tends to be a failure. When in loopback a UART talks only to itself (and thus the UART will tend to agree on settings and you are guaranteed it isn’t a difference between UARTs getting in the way). Once you check settings on each side as working in loopback, and verify that the serial software is using the same settings on both ends, then you connect the UARTs to each other and do the real testing. Try on just the Jetson side, and then just the host side, wiring the TX and RX together, and the CTS and RTS to each other as well. Run your minicom against that and see if (with local echo off) you still get echo.

If you get echo with this, then both ends should be able to talk to each other normally. If not, then there may be a device tree issue (which is part of the BSP for the carrier).

Hi Linuxdev,

sorry for not replying earlier but I was on vacation.
I did what you suggested (coupling the RX to the TX) with some very interesting results.
So I had two terminal windows open, I tried the most basic of interactions with the serial port. In the one terminal window I had a cat /dev/ttyS0 running so that side was listening and in the other I did a sudo echo T > /dev/ttyS0.
When I did this once, I got one T at the listening side, when I did this once more I got a T then a new line and other new line and a T again, but it didn’t stop there, it kept going with 5 more new lines and yet an other T, then 12 new lines and an other T
In short the new lines kept on doubling in occurrence and the T kept on coming. I actually routed everything to a file just to check this behavior and had to stop it since the file size was exploding.
So when I remove the tx and rx physical connection it stops obviously but when I try this experiment again it happens all over again.
I don’t understand what is happening here can you make sense of this?

Keep in mind that I’ve never seen a Spacely carrier board. Can I verify that the Spacely carrier board does not use ttyS0 as a serial console? On the dev carrier this is serial console. Attempting to use this for both serial console and regular UART at the same time would lead to quite bizarre behavior. I could see the possibility that sending random data (so far as consoles are concerned) to a console would cause odd replies. Including loopback of TX and RX on a console would have the shell talking to itself, along with random data being injected.

If it is a case of the serial device not colliding with serial console, then there are some other possibilities, but in loopback mode many of them are eliminated.

Yes, you are correct. I’ve verified this with someone from Connect Tech and this is indeed expected behavior if I simply connect the Rx with the Tx. Anyway it does prove that I can send and receive on the UART0 so that answers my question.

Thank you for the help and patience.