we have been experimenting for a while, with various devicetree and config changes - to make use of the third UART on the Xavier NX.
Ideally we want to add an additional serial peripheral (a STM32 microcontroller) on this port, and do reliable bidirectional comms with it. We have LIDAR and other seral
This, by default, uses the ‘combined’ or tcu driver - and appears as /dev/ttyTCU0
By default, on startup, there is a lot of logging output sent to this port, as far as we can tell by the BPMP.
Once the system is running, it is possible to use /dev/ttyTCU0, but it has unwanted line-ending behaviour, as well as observing strange ‘replace 0xFF with 0xFF0xFF’ behaviour when sending bytes via this port. A look at the driver source e.g.
shows this clearly, and these translations make it quite unsuitable for a ‘raw’ serial device.
So, we attempted to disable the combined uart driver, and enable the ‘normal’ serial driver for this port - as far as we can tell, successfully - with our devicetree modifications we were able to bring up a /dev/ttyTHS2 - but loopback connections stall after a few bytes, and bidirectional comms (e.g. between minicom running on the Xavier NX and a laptop - do not work as expected at all, it seems like output is lost, and buffered in strange ways:
e.g. data will only be passed sent from the jetson on the tx, when a byte is received on its rx, and frequently, where data is sent from the laptop, it is lost - e.g. a sequence of typed digits ‘123456789’ might be received as ‘1235689’ or similar.
This makes /dev/ttyTHS2 unusable for our purposes too.
Possibly, what we are seeing is some side effect from peripherals like the BPMP, or others, ‘sharing’ the debug connection, even when the combined driver is not loaded, but whatever the issue is, it is very confusing.
There are numerous posts in these forums, which detail, as far as I can see - only partial success in being able to use UART3 as a ‘clean’ UART, with references to a multitude of postings, none of which ever seem to end in confirmed success doing this.
So I would like to ask the following:
Is it possible to completely disable the use of this UART, other than from user-space after the kernel is booted? e.g. when powering up the Jetson Xavier NX - no output whatsover should appear on this uart, from any peripheral.
Once the kernel is booted - is it possible to send and receive data on this uart reliably via the tegra highspeed uart driver, as if was a standard port behaving the same way as the ttyTHS1 device?
If the answer to the above two questions is yes, what is a clear set of steps to acheive this - following some of the advice in the other threads, specifically setting the BPMP uart to Oxff instead of 0x03 - seems to stop the NX from booting up at all, for example, and it is very hard to know how to proceed.