I’m using UART0 (/dev/ttyTHS0) on the Xavier NX. I have a userspace control class that constantly polls the Serial RX buffer, and runs a callback if the buffer is of non-zero size.
Nominally, this code is very quick, often taking less than 50 ms. However, under unknown and inconsistent conditions, this code is very slow, one iteration taking sometimes up to 10 seconds.
There are some things I’ve noticed about this phenomenon. There has never been an instance where this bug persists longer than one iteration of the loop. The following iteration then “cleans up” the bottleneck by performing the callback on all the bytes that were buffered due to this weird hangup. Additionally, this bottleneck does not always repeat itself, but I’ve noticed that it seems to happen in 5 second intervals when it does.
Attach is an image of a profile I did showing the behaviours I described; one being the inconsistent hangup, the other being the occassional 5 second periodic repeat.
I also have a hunch what this might be too, but can’t confirm it. UART0 I believe is tied directly to CPU core 0, which is the main interrupt servicing core. In the Xavier NX documentation, I see there is another UART nested in what’s called the CBB, but I imagine that’s a hardware interrupt fabric accessible by any core. My primary thought is a hardware interrupt kicks my receive callback off CORE0 sometimes, and no other core can take over that load because only CORE0 can access that UART. If I can figure out what the pins are for the UART embedded in the CBB, as well as how to enable it (if not already enabled), I could use that to test my theory.
All I want to gain from this topic is a fix to the problem. Whether you know why I might see sparadic delays in my callback, or you know how to use the UART embedded in the CBB, either would be greatly appreciated.