I have an TX2 connected to an Elroy carrier board. I am connecting an IMU module to the Elroy using UART. I’m accessing the device via ttyS0.
I’m having two issues:
The first issue is the baud rate. I cannot receive data from the IMU at a baud rate higher than 115200. I looked in this forum and I’ve seen things about using two stop bits. Now I cannot modify the firmware of the IMU module to use two stop bits so am I stuck at 115200?
The second issue is that the whole system crashes sometimes. I would start data collection from the IMU and the system crashes, restarts and freezes at the nvidia start logo. Then I’d have to turn the power off and on again to be able to boot. However, if I don’t have the IMU connected via UART, this issue does not happen.
What can I do to resolve these two issues?
Thanks
It isn’t ideal, but you could use a USB serial UART (such as the serial console normally uses). However, speeds above this work, just not with a sufficient clock timing precision. There should be no reason why trying or using serial console at any speed would cause any sort of crash. I could see that if a program can’t handle corrupt data, then that might be a crash issue, but the actual UART, even with corrupt data, would never cause the system to fail.
One also has to be sure that when using a UART for data that the same UART is not already used as a serial console. If that UART happens to be set as a serial console, then everything going through the UART is essentially garbage being fed to a terminal.
I don’t know what is needed on the Elroy carrier board, but this will of course have a custom device tree provided by the manufacturer. In most cases ttyS0 is serial console, but you can examine where the nvgetty.service is running and see if it is either ttyS0 or ttyTHS0 (both use the same hardware, where one is the traditional serial driver, and the other is the “Tegra High Speed” driver…software would use one interface or the other, but not both):
systemctl status nvgetty.service
If it turns out the service is actively running on either ttyS0 or ttyTHS0, then I’m sure you’re going to have a lot of interesting issues since content you write also goes to a terminal, and replies from the terminal would go to you. It is fairly simple to disable the service if this is the case, but it would be better to keep serial console and move the data to a different UART.
Thanks for your reply!
My requirements dictate the module to be connected over UART.
This said that the service is running on ttyTHS0 and my IMU module is connected to ttyS0. I tried to disable the service anyway using
sudo systemctl disable nvgetty.service
But it didn’t do anything. The system is still crashing, and when it crashes it gets stuck at the nvidia logo and does not boot until I turn it off and on again. If I disconnect the IMU module, everything works just fine.
What should I do? :(
Edit:
Maybe this detail might help:
When the IMU is connected and the board is not connected to power, connecting it to power and turn it on will boot just fine. Then crash after some time and get stuck at the nvidia logo, and cannot do anything until I disconnect power and connect it again.
Even if it hasn’t crashed yet, and I rebooted when the IMU is connected, it does not boot and gets stuck on nvidia logo.
Another thing I noticed, is the data of the IMU isn’t right. I have a piece of code to log IMU data to a csv file. After I run the data collection script, I check the csv file, the data is recorded just fine but after some point, all the variables are recoreded as zeros. Which, of course, is weird.
This means both are using the same UART at the same time, but with different drivers fighting for the UART. This is incompatible. The result is undefined.
Note that if you touch the serial console UART during early boot stages, then this could halt boot or cause strange behavior.
FYI, a USB serial UART is a UART like any other. This would also avoid two drivers and console using the UART simultaneously. At the very least it would be a very good bit of debug information, and would eliminate the need for 2 stop bits at higher speeds. Many such serial UARTs with an FTDI chipset won’t need any extra driver and are in the $15 to $25 range.
So in this case, if I want to avoid strange behavior, should I not use the UART at all?
The “/dev/tty…” will change when you use a different UART. The strange behavior will go away since only your program and a single driver will be used without conflict. Using ttyS0 and/or ttyTHS0 will cause conflict.
I changed it to ttyTHS2 and now the crashing problem is solved. Thanks!