Greetings: I'm trying to come up with a proper technique for resetting our LCP2292 from code. If one searches long and hard enough, there are a few existent notes out there that recommend resetting by letting the WatchDog Timer timeout. The inference is (and this is nowhere supported by documentation I can find) the WatchDog timeout will not only reset the ARM core but also the peripherals (RTC, etc) contained in the LCP2292. I suppose my first question would be: Is this true? I am currently writing handlers for such nasties as the Abort and Undefined interrupts. If I end up there, I log the interrupt but then I would like restart from the beginning. The trouble is once in these interrupts, one is no longer in User/System mode and the WatchDog is not available. I can, of course, just jump to address zero, which seems to work, but I worry any off ARM core peripherals will not also be reset by such brutish and heavy-handed methods. Of course, good code should never end up at those dead ends, but frankly during development, I have seen instances of data and prefetch aborts. These are thankfully absent now, but as this application is mission critical, it really needs to recover should such unexpected things ever happen again. So..., is there a prescribed or recommended technique to really reset the LCP2292? Thanks, Doug
The trouble is once in these interrupts, one is no longer in User/System mode and the WatchDog is not available. I am not sure what you mean by this statement, if you are already handling an exception, you are in a privileged mode with the same "privileges" as if in sys_mode. Are you writing the handler in asm or C? Why can't you access the WD registers from _abt mode? Yes, mov pc, #0 will do a "warm boot". If you have the resources, an external voltage regulator with \RST input would be a way to go, like TI's TL7733 (also has a programmable delay for V-ramping up). Then you could toggle outpin pin on LPC to issue reset for TL7733 from the exception handler. But this reset might bring you back to the exception that originated this reset, and oscillation might be due..is that what you want to do? Of course, good code should never end up at those dead ends, but frankly during development, I have seen instances of data and prefetch aborts. Good code, hm? :-) If there was such a thing, we would not need to worry about exception handlers.