Hello,
I am using a Jetson NX with devkit carrier board (L4T 32.6.1) and currently using ttyTHS0 and ttyTHS1 serial ports just fine. I would like to convert the serial debug port into a normal uart port as I need a third serial port.
I disabled combined-uart and enabled serial@c280000 in the device tree
I removed the serial{} part in the bpmp
After the flash, /dev/ttyTHS2 appears in dmesg and in the filesystem.
When connecting ttyTHS0 and ttyTHS1 to my PC with a standard USB adapter, communication works correctly (using screen /dev/xxx 115200). When I type text in either terminal (pc or NX), characters are sent and received immediately by the other side.
Now if I do the same on /dev/ttyTHS2, communication is strange:
For the Jetson TX pin: when I type text on the jetson terminal, I have to press a key on the pc terminal to receive what I typed, as if the Jetson NX had a ‘send buffer’ awaiting an event on the RX pin. If I only keep GND and Jetson TX → PC RX, I never receive the data on the PC.
For the Jetson RX pin: when I type 123456789 in my PC terminal, I only receive some of the data: usually 459 for example.
If I loop back RX to TX on the jetson and send some text, I never receive it (nothing happens in the screen terminal).
Furthermore, I did not disable cboot uart logging, which means I receive debug data from Cboot when I start the Jetson NX on my PC terminal, and I can interrupt the boot sequence just fine by typing data. No character is lost in the process. It’s as if something was launched after the boot altering the ttyTHS2 port.
stty -a yields the same settings on ttyTHS1 and ttyTHS2
I also tried on the latest L4T 32.7.1 today, same behaviour. UART console works fine during boot stage, stops after cboot as expected, then cutecom exhibits the same behaviour. I am using the developper kit carrier board.
If I do not perform the serial port modifications, communication on combined uart ttyTCU0 works correctly but I am getting spammed with kernel messages on the serial port.
Is disabling combined-uart in device tree and enabling serial@c280000 enough or am I missing another step?
please check $ dmesg | grep THS for the register node of uartc: serial@c280000
BTW,
you should look into pinmux cfg and device tree definition for the mappings.
for example,
I ended up reenabling combined-uart and removing bpmp, cboot and kernel console, providing me with a clean uart after boot. If anyone knows how to bypass the use of combined uart to directly use ttyTHS2 instead, I’m interested!