The title of this post is rather ambiguous and can be read several different ways. This is no accident as it reflects the ambiguity that I see concerning the most fundamental event in an embedded system’s life – reset. Being a consultant, I get to write a lot of my own code. I also get to read a lot of other people’s code and the one area where I almost never see much thought given is to handling the various causes of a system reset. In the bad old days, you were reset and that was all you knew. Today, however, modern processors contain registers that may be interrogated to determine the cause of the last reset. For example, an AVR processor I am working with lists the following possible causes:
Power Up
Brown Out
External Reset
WatchDog
JTAG
Based on my experience, I’d say that 99% of the embedded systems out there don’t care what caused their last reset. This strikes me as foolhardy. At the very least, an embedded system should keep track of the number of times it has taken a watchdog reset for post deployment quality analysis (you do do this don’t you?). Furthermore, a portable system should take remedial action if it underwent a brown out reset – presumably indicating that the battery is failing. As for a JTAG reset, could this be construed as an attempt by someone to determine the inner workings of your system – and if so what should you do about it?
I have been involved in systems where support for handling the different interrupt sources has been added as an afterthought – and it shows. As a result, I’ve come to the conclusion that the only way to handle this is to think about it from the start, and to know up front what needs to be done for each of the different reset sources. If you go through this exercise, you’ll find that your startup code becomes a lot more sophisticated. You’ll also find that you’ve designed a better system – which after all is the point.
