can any one have watchdog interrupt handler for LPC2366. i dont know what to do inside watchdog interrupt handler.Is clearing bss and scratch area in lpc2366 is must?if so how to implement it.Is copying stack to ram area is must?if so how to implement it.How about uninitilised data section??can any one have any idea?
Why do you think you would need to copy any stack etc? Are you really talking about a watchdog interrupt - it seems more like you are thinking about a watchdog reset.
If you configure the watchdog to generate a reset, you don't need to do anything else than to kick/feed the watchdog regularly. If you fail, the processor will reset and reboot your program almost identicall to a power-on reset. The only difference is that the RSIR register can be read and it will tell you that it was a watchdog restart and not a power-on reset, or an external reset or a brownout reset.
if you mean a periodic interrupt that the watchdog can generate, I think that an example exists for that in your toolchain's path - namely, "..\ARM\Examples\ST\STR91xLib\WDG" or your respective path for the ARM7. Look at your 71x_it.c file for additional information.
Since the OP asks about "clearing bss", "copying stack", "uninitilised data section" it sounds like the idéa was to restart the application.
hi, Thanks for your reply.u r correct..what i planned was to reset the processor and restart my application whenever watchdog wil generate interrupt. for this "clearing bss", "copying stack", "uninitilised data section" are necessary .right??so only i am asked how and where the above section to be implemented.
You just configure the watchdog to generate a reset. After that, you only need to make sure that all time-consuming loops contain watchdog kicks. As soon as you fail to kick/feed the watchdog, the hardware will take care of the rest, i.e. you do not need any watchdog interrupt handler.
Inside main(), before you enter your infinite loop, you may decide to check the RSIR register to figure out if your program was started because of the watchdog reset, and possibly take corrective actions. You might for example use the 2kB of battery-backuped memory to store information about what submodule that resulted in the watchdog reset, so you could avoid problems with continuous watchdog resets because of a software bug in relation to some broken external hardware.
But all that is optional. Right now, it is enough to initialize the watchdog and insert the required watchdog kick calls to keep your application working without false watchdog resets.