If you have a serial console it may show information not available when the rest of the system freezes. It’s just the DB-9 connector set to 115200, 8N1 (RTC/CTS flow control). I use this with gtkterm, or sometimes with minicom. If you run Windows, then PuTTY works.
Perhaps if you had a text terminal up running this command it might show something right before it freezes:
sudo tail -f /var/log/kern.log
It is also possible that after reboot the rotated log name would have info:
In the case of a directly connected keyboard (or alternatively through echos to “/proc/sysrq-trigger” under serial console) you may be able to use sysrq to explore causing an OOPS dump on purpose (this would be much more informative than just knowing the system freezes). See:
An example might be if you had a directly connected keyboard and wanted to “more safely” reboot a locked system…should magic sysrq function, this key combination would reboot after setting partitions to read-only:
ALT-SYSRQ-s # syncs the disk
ALT-SYSRQ-u # remounts disks read-only
ALT-SYSRQ-b # immediately reboots
Note from that URL that you can also do other things, such killing processes or causing register dumps on some architectures. You might see what is possible prior to connecting the device by sync and read-only mount, followed by seeing what happens when you do various kinds of debug dumps.
If you must use a serial console then you cannot run directly via keystrokes (it’d act on your host, not on the Jetson). Instead you can echo characters to “/proc/sysrq-trigger” and get the same result if serial console has survived. And of course if serial console has survived you might be able to find out what is going on without ever using magic sysrq keys, e.g., dmesg.