It's not a good thing anyways that the watchdog is disabled in the startup code. Aside from endless loops in buggy code, the main reason for using the WDT at all is that the processor resets if it has crashed by some ESD or similar issues. If the processor restarts while the crash-causing condition is still there and the WDT is disabled in the very first operations, the processor might hang and never reset, rendering the WDT completely useless. Moreover, since the normal mspgcc user is nto told that the WDT is disabled at the very start, he will assume (as I did) that the WDT is active after reset/PUC and maybe never activate it at all. (especially if the WDT is initialized and triggered by a read-modify-write macro). This caused me a LOT of headache before I figured out that the startup code deactivates the WDT.
I know that initializing the variable fields at startuop can take longer than the WDT interval on processors with more RAM, but it would be way more compatible to use a slower startup code that triggeres WDT than using a faster but incompatible code that forces people to 1) notice the difference between datasheet and reality, 2) figure out that the automatically embedded and therefore invisible startup code is the reason and 3) write their own startup code. Normal users usually don't even try to understand the final .lst file, and that's the only place where you can find it. JMGross ----- Ursprüngliche Nachricht ----- An: GCC for MSP430 - http://mspgcc.sf.net Gesendet am: 03 Apr 2009 10:04:32 Betreff: Re: [Mspgcc-users] changes of the memory mapping for family x5xx > in the new x5xx family a lot of the memory mapping of the peripherals > has changed. > In particular, the watchdog is now defined as: [...] > In the libgcc.S file there is: [...] > where the watchdog address 0x120 is hardcoded. This is correct for > every MSP except for the newer x5xx family.
