Is there a recommended method for restarting an RTX51Tiny process in case of hoseup - something less drastic than restarting the entire processor (e.g. via a watchdog)? I have several interlocking processes that may lose synchronization, and want to be able to restart them as a last resort, say from a monitor process or long-duration timer interrupt.
You're asking for the impossible. It's basically the definition of a "hose-up" that nothing less drastic than a hardware watchdog bite will get you out of it, because everything else has been tied in the hose-up. You're effectively asking the wrong question. It's unimportant how you get out of a hose-up --- the trick is never to get into one.
Well, when you have multiple processors trying to communicate, sometimes things can go askew. For instance, I have an embedded system trying to talk to a host system over an RF link. It is possible that the host can drop off in the middle of a tranmission, in which case I have to reset the protocols and go back to waiting for contact initiation. I could put tests into every point where I wait for a reply (basically where the interchange handler sends something and then calls os_switch_task while it's waiting for a reply) or I could just set a long duration (say 10 second) timer and have the timer ISR reset the protocol handler.
"Well, when you have multiple processors trying to communicate, sometimes things can go askew." This is precisely why protocol stacks are expensive! It has been said that only, say, 10% of the development work goes into handling the case where everything goes right - the other 95% goes into handling all the possible failure conditions! "I could put tests into every point where I wait for a reply" There is no "could" about it - you must have those tests! "or I could just set a long duration (say 10 second) timer and have the timer ISR reset the protocol handler" Well, if you're happy that your comms keeps locking up for 10s at a time...
It is possible that the host can drop off in the middle of a tranmission, in which case I have to reset the protocols and go back to waiting for contact initiation. Well, that's not a hose-up. That's just a plain vanilla protocol time-out. How exactly that has to be handled depends on the details of the protocol, and potentially on the reasons for the time-out. Other than that, the only possible comment is that well, all the trivial things have long since been done by others, so guess what's left for you ;-)
See: http://www.keil.com/support/docs/307.htm