I have a two board [AVR] system, where it is possible (though unlikely) that one of the boards may reset unexpectedly - brownout, watchdog, stray neutrino (i.e., SEU), etc.
I need to be able to recover from one of these and try to keep the overall system functional. I.e., the state of one board is related to the state of the other. Note, the two boards can communicate to each other via wireless link.
I am familiar w/ how to use the MCUSR register to nominally determine the source of a reset. My question is how best to revert to the previous state upon recognizing source of reset. As I see it, I have two options.
1. Log the current state to a fixed address in EEPROM. At power up, if not detected as a power on reset, check logged state, and revert to that state.
Pros: fairly foolproof, self contained
Cons: Requires relatively frequent updates to a particular address in EEPROM.
Altered approach: have the address of the last known state be pseudo-randomly (or deterministically, i.e., incrementally) dynamically determined at run time. Then log the state-address in a special section of EEPROM for personality data. Now this address will be written to at every power up, but at least it is only once per power up (state will change multiple times.). The randomly selected address containing state data will be written to probably five to ten times per power up, but given that I have 4kB of EEPROM, it will take close to 4000 power cycles before I revisit that address. If each address is written to 10 times, and has an endurance of 100,000 writes, that means the EEPROM technically would survive 40,000,000 power cycles ((100,000 / 10) * 4000). Obviously, the smaller limitation would be the address in the personality space containing the location of the state data -- 100,000 power cycles.
Option 2: Have each board track the other board's state. After a [non-power up] reset, query the other board to determine what state the reset board should revert to.
Pros: no non-volatile memory limitations
Cons: Won't work if both boards reset simultaneously. Requires both boards to be awake. In my particular application, one of the boards is almost always asleep - to conserve power. It would introduce an additional power drain to wake up periodically (i.e., 100ms every 1s) to listen for potential state queries
I am looking for feedback regarding these two options, or for another option that I have not considered. Which seems better?