I decided to base the next version of APSync on JetPack 3.1
Unfortunately, I’m having a few issues with obtaining a serial connection to the flight controller.
It seems any access to /dev/ttyTHS1 is sufficient to instantly lock the board up. What I’m assuming is a hardware watchdog reboots the board after a minute or so. If the access to the serial port is made on the first tty (ctrl-alt-f1) no further output occurs on that terminal until the board reboots.
“stty </dev/ttyTHS1” is sufficient to kill the board
“screen /dev/ttyTHS1” is sufficient to kill the board
I’ve poked around a little bit:
removed the console= line from the kernel commandline (expanded ${cbootargs} in /boot/extlinux/extlinux.conf and removed that specific parameter)
ensured the getty/login combo isn’t active on /dev/ttyS0
This seems so easy to provoke I’m somewhat surprised I’m unable to find evidence others are not having similar problems.
This is a long way from being particularly helpful, but consider that ttyS# devices use the standard 16550 UART setup, while the ttyTHS# devices are designed to support a DMA transfer (they are different drivers…U-Boot does not support DMA and so sets up ttyS0 as a 16550 UART without DMA). If you were to use a ttyTHS device which did not have DMA set up, then I would expect an attempt to read/write an invalid DMA address. Can you use stty or screen on ttyS instead of ttyTHS?
Have you tried testing various settings while doing loopback? Connect RX to TX, and CTS to RTS. Then attempt screen or other terminal…typing in should echo back if it works. This could be tried at different speeds and with or without CTS/RTS flow control. It would help if you can get echo at lower speeds on one of these without crash, and then increase speed to find the limit. Knowing that ttyS0 or ttyTHS1 works at any speed in loopback would be a very strong hint as to which driver is active.
Btw, I’ve seen another case of higher speeds on the serial port (ttyTHS2, connector J17 on the dev board) be unreliable, but I believe the speeds tested were faster than 921600.
Have you done any kind of device tree change? I’m not sure what would be required to convert J21’s serial port from ttyS0 to ttyTHS1, but device tree configuration has changed between prior releases and R28.1. You might look at the device tree in the working version and compare with non-working…the two might not be identical anyway since there is a lot of change going from the 3.x kernel series to 4.x kernel series.
If you want to extract the exact current definition of device tree on a running Jetson you can do this:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
# To find serial controllers:
gawk '/\tserial[@]/,/[}]/' extracted.dts
# Compare between older working and current non-working version...
If possible please give an exact/detailed list of what was done to disable serial console (basically what needs to be done for someone else to repeat this).
@linuxdev Apologies for the slow response here. My cycle time on the TX1 is quite long due to the time taken to flash, which I haven’t gotten down to a fine art yet…
I have not attempted to work with the /dev/ttyTHS1 with the serial port in any configuration except “known working” and “unplugged”. Behaviour is the same in both cases.
I have done no device tree change on JetPack 3.1 - yet! I will dump the device tree from 3.0 and compare it to 3.1 (I note the kernel version is 3.10 in JetPack 3.0, 4+ in JetPack 3.1…
I took just two steps to disable serial console:
use systemctl to disable and stop the service
modify /etc/extlinux/extlinux.conf to (a) expand the kernel command line options usually filled in (by u-Boot?) and (b) remove the references to console=/dev/ttyS0 in that expansion
Note that any access to /dev/ttyTHS1 - even just to get the properties - kills the TX1. So “stty </dev/ttyTHS1” on a freshly booted image kills the TX1. That action should be independent of whatever baud rate the port is set to. I have also attempted to start screen with different baud rates - they all lead to the same thing, board lockup and (eventual) reboot.