TCU0 is unable to correctly send or receive the byte 0xFF

When sending or receiving data through TCU0, we noticed that the byte 0xFF is sent twice every time we send it, and is only received every other time when receiving. We have gone through some steps to disable the debug console, such as removing the reference to TCU0 in extlinux.conf, but we still are seeing this issue. We have also configured TCU0 with -ixoff and -crtscts, and removed some references to TCU0 and changed the combined_uart and spe_uart fields when flashing (in Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-misc-flash.cfg and in Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-misc-l4t.cfg).

Is there something else we need to do? We are using the ConnectTech Hadron carrier board.

Hi micky4,

It seems you are using the custom carrier board for Orin NX.
What’s your Jetpack version in use?

May I know what’t your use case for debug UART?

Combined UART will output debug messages from several firmware like MB1/MB2/SPE/UEFI/kernel…etc.
It is not easy to be disabled and we don’t suggest to do this.
Please keep it working as debug UART and use the other 2 UART interfaces for your UART device.

Hi Kevin,

We are using Jetpack 5.1.2.

We are limited by the physical connections, so this is the only pin we can use.

We have to convert the debug UART to regular UART, we really don’t have any other way. I understand it’s not typically suggested and may be difficult, but how would we convert it to standard UART? Thanks for your help.

Do you mean that the board is not at your side?

There would be still the other 2 UART interfaces available to be used.
One is on 40-pins expansion header, another is on M.2 Key E.

May I also know know what’s your use case for the UART?

Our hardware configuration allows us to only connect to the 40-pins header. On our carrier board, this 40-pins header has the debug UART and 2 RS-232 pins. We cannot use RS-232, so we are only left with the debug UART.

We are using another device that can only be connected to via UART. We don’t want to resort to a hardware solution that would require an interface to be introduced, so ideally we connect the Jetson UART to the other device’s UART.

We’ve done a thorough analysis of our options and this is essentially the only solution. Is there no way to fully configure the debug UART to be a standard UART?

What do you mean the “debug UART” on 40-pins header?
Could you share the PIN number you mean?

The debug UART I mean is from the PIN3/PIN4 of J14 header.
Yes, we don’t support using this UART interface as normal UART currently.
In Jetpack 6, we even remove the node in device tree(i.e. uartc@c280000)

On our carrier board, I am talking about pins 37/38 on the 40 pin header (https://connecttech.com/ftp/pdf/CTIM-00088.pdf) that correspond to UART2_RX and UART2_TX. I think this is the same as PIN3/PIN4 of the J14 header on the development kit.

Is there a reason this is an unsupported use case, and is there a possibility that this will change in the future? I have seen a few posts regarding this topic, though it is unclear if there is a method of disabling the debug functionality completely. Are you saying this is not possible to do, or just that Nvidia does not support this?

Then it is the debug UART as I guessed before.

We won’t support this use case since it is combined UART, which will output the debug messages from several firmwares like MB1/MB2/SPE/UEFI/kernel…etc. It’s not an easy work to disable all of them. The firmware should be modified to disable it but some firmware is not permitted to be modified by the user. Please use other UART interface to communicate with your UART device and just keep the debug UART as it is.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.