Even though it seems that this topic has reached a sensible conclusion, I just wanted to add information I've gathered to help others who may run into this sort of situation:
Daklu wrote:
...
I have an application written in LV2013 running on an sbRIO-9606 with CompactRIO 13.1 installed. Under certain conditions we do an automatic reboot using the RT Restart Target vi from rtutility.llb. Occasionally, the device will reboot into safe mode (improper installation) instead of run mode. (I'm rebooting every 3-4 minutes for the purposes of figuring this out. In production reboots may happen as often as every 20 minutes.)
I know we're not running out of storage space as was the problem with a previous user. I also know about the YouOnlyLiveTwice key, and using that seems to prevent the device from rebooting into safe mode, but I'd rather address the root problem (something unknown is triggering safe mode) rather than mask it (prevent it from entering safe mode when it thinks it should.)
NI Linux RT is a different beast altogether: if LabVIEW RT crashes (either due to an actual bug in LV or your application, or issues in libraries used by your application), the OS will not reboot. Instead, LabVIEW RT itself will be restarted (one of the benefits of a dual-mode OS). If this happens twice, if you have configured a startup application (and have not set the "YouOnlyLiveTwice" token), LabVIEW will not load your startup application (it's likely that something in the application is causing LVRT to crash).
VxWorks, being a single-mode OS, has no notion of a separate "process". LabVIEW RT is just part of the OS, the single process that is running on the system. The OS has a notion of threads, different sequences of execution with a shared memory space, and this is how LVRT on VxWorks (and Pharlap ETS) provide multithreaded support. This is also why, if a LabVIEW RT application misbehaves on these targets, it will cause an OS-level exception. This means the OS can no longer make guarantees of the sanity of the shared memory space (or processor state, for that matter). This exception will reboot the controller to restore a known good state to the OS.
On a normal reboot, a section of non-volatile memory is used to track this notion that the system reset was application-requested and that things shut-down cleanly. On an exception, the code that handles the exception uses this same area of non-volatile memory to keep track of how many times the system has restarted due to system crashes. If they exceed one, the default action is to reboot into safemode.
Now, the tricky bit is that, depending on what's going on in your application when you've requested a reboot of the target, this can lead to crashes. This is particularly tricky since, externally, it seems OK: you've requested a reboot, the target, indeed, did reboot. The issues come in when you see the situations that you're seeing: that the reboot requests actually triggered a crash and ultimately lead to the target booting into safemode. This was done in the hopes of making sure your target would be remotely accessible in the event of a problematic app (if the OS is continually rebooting, you can't access it from MAX).
Finally, a button-press reboot does not modify the "crash count", it doesn't zero it out, it doesn't increment it, so it doesn't really play into this.
