I’m trying to use BrSystem function Block SysInfo to try to detect a reboot into service mode. My intention is to use this block and other code to detect if an operator has adjusted settings which have caused issues and therefore loading a known good set of parameters on reboot into Run mode.
However I’ve been trying to test the block by calling a bad memory copy (brsmemcpy(1,1,1)) to trigger a page fault or calling an infinite loop to trigger a cycle time violation and therefore booting into service mode. I have not been able to get the init_reason to come up with anything other than 1 (warm restart) or 2 (cold restart).
Is it my test cases? Or is there something I can trigger to get the block to return 4, 8, 16, 32, or 64 for init_reason?
Hmm, that’s tricky… I’ve no idea right now how to detect a previous service mode by user code (instead of reading logger information and trying to figure out if the boot before the last boot was not a warm or a cold restart). Maybe someone else has a great idea?
The reason why you only get the init reason warm or cold restart is, that the user code isn’t executed when booting into service or diagnose. And because you can’t leave service or diag without a warm or cold restart, your user code will only see this restart reason, but not the state before the the last restart.
My only other thought would be define Exception tasks and create a Global retained variable which would be saved through service mode and warm restart to somehow trigger the reload to overwrite bad settings.
But not every thing that can put you into service mode is detectable through Exception Task Classes (though anything the user could potentially influence may be caught, i.e. a watchdog issue is likely more of programming error than a user setting change error).
Good idea!!
I agree, it’s also my experience that most issues caused by wrong user parameters would lead to cycle time violation or pagefault, both can be caught by exception tasks.