01-26-2015 10:33 AM
The question is simple: is there a way to detect if a system reset was triggered by a watchdog event instead of power-on-reset?
Thanks
Luca
Solved! Go to Solution.
01-27-2015 08:57 AM
Just for clarification, I would imagine you are interested in knowing from a LVRT application on the target, is that right?
01-27-2015 08:59 AM
Yes, the idea is to be able to do a post-event log and differentiate from a power-on-reset. Otherwise it's impossible to know if the reset was caused by the WDT or a problem in the power supply or the O.S.
Thanks
Luca
01-27-2015 09:46 AM
I don't know if there's a friendly UI way to do that, but you can use the System Exec.vi utility VI to read the "reset_source" pseudo-file (on my myRIO and cRIO 9068, it is located at /sys/devices/amba.0/e0004000.i2c/i2c-0/0-0040/reset_source).
Check it first on the serial console or SSH (or monitor/keyboard if we're dealing with one of the newer x64 cRIOs), then wire up the System Exec with the same command you ran and check for "watchdog" being returned from reading the file.
01-27-2015 10:21 AM
Thanks. That is exactly what we were looking for!
Luca
01-27-2015 10:39 AM
We are having problems with file permissions. From SSH everything is fine, but from the application we cannot read the file, since it has permissions 400 (only owner can read it).
Any workaround?
Luca
01-27-2015 10:57 AM
A shorter and less device-specific path to it is /sys/bus/i2c/devices/0-0040/reset_source
01-27-2015 11:02 AM
Bleh. Not an easy way. You could add a startup script to check and change the permisisons of the file.
This is a pretty resonable resource on writing and using a startup script: Tutorial: Installing Startup Scripts on NI Linux Real-Time
You'd want the script to use ls -l /path/to/file to check the permissions and chmod +r /path/to/file if the permissions are wrong. (note: you could also use chmod 444 or chown lvuser, but just use the +r)
01-27-2015 11:29 AM
Great. It works perfectly!
Luca
01-27-2015 12:29 PM
sirluke wrote:
Great. It works perfectly!
Luca
Great to hear! Sorry it wasn't quite as friendly or UI-centric a way to get to where you needed to be, but we got there.