----- Ursprüngliche Nachricht ----- Von: Chris Liechti Gesendet am: 15 Mrz 2011 20:26:40
>> It's not only that the datasheets talk about disabling the watchdog. >> Disabling an already disabled watchdog does no harm. > neither is enabling it again a problem, if you actively want to use it. But not enabling it when the docs say it is enabled while it has been disabled by the compiler _does_ do harm. > in that case you only have a small time during startup where the > protection is not good. however the startup phase is a few milliseconds > compared to hours or months of normal operation afterwards. There are many devices where the MCU is only powered when an event occurs. The MSP is no chip for a router that runs for mothn without reboot. It is for devices which require low power consumption. And the lowest is shutting down when not required. :) That's what the new .5 LPMs were designed for. However, being unprotected for some milliseconds (which is an eternity) while you think you are, isn't good. In fact, it is way worse than being protected when you don't think you are :) > a hardware watchdog is also often used to protect against programming > errors (e.g. not enough stack space for all combinations of interrupts > and foreground code). this kind of protection is not needed during > startup as the code there is proven (and interrupts locked). Using a WDT for dixing software bugs is very bad style. What happens? The device resets and runs into the same condition again. It's a dirty way to 'fix' defective code or faulty program design. > it is an issue when you expect extreme EMI, during startup, that > disturbs the operation of the CPU, causing it run faulty instructions. > however, in such a scenario, what makes you think that the WDT module > continues to work properly... Because it is simple. A simple, R/C osc clocked counter that pulls the reset line when it overflows is by several magnitudes more robust than a complex micture of CPU core, ram, flash rom/controller etc. In fact, it WAS the EMI problem on our devices (energy metering in an industrial environment) that made me using the WDT. And it often happens that a heavy spike in the supply makes the BOD trigger a reset, followed by a device crash due to EMI aftershock. With a disabled WDT in the startup code, the devices ceased to operate. with WDT, they restart over again until the supply is clean again. > (i've never seen an MSP running faulty by > EMI. i've only see it behaving badly when the clock was out of specs. > that's one of the points that the F2xx fixed, compared to F1xx. there is > an additional glitch filter for MCLK) Fixes in 2x won't help you if the (admittedly older) designs use the 1x :) Well, most of the 1x don't have a BOD, so they won't reset due to EMI on the supply - they will simply crash (as they don't even have an SVS). > if you want to rely on the watchdog, you should also realize that you > have to reset the WDT module - in your application - before it expires > and resets. That's obvious. But useless if the watchdog has been disabled without you knowing it :) > i'd also point out that using a WDT module correctly requires some > thinking. just restarting it all over your code isn't giving good > protection. restarting it in interrupt handlers isn't good either (as > interrupts may still somehow work even when SP points to non-RAM). Indeed. As is using a WDT for 'fixing' software problems in general. If you want a WDT for your software, you should better implement a software WDT: In a timer ISR (may use the WDT as timer, as it causes a non-maskable interrupt), you check and increment a set of global variables. At certain points in the code, you reset them. If a variable isn't reset before it reaches a certain (and maybe individually configurable) limit, the ISR will write an entry into the error log an THEN cause a reset (or do any other action). So there are multiple triggers which are ORed. This works even for multi-threading systems. I implemented it for an ATMega128 system running NutOS and it works perfectly. P.s.: On the ATMega, there is even a fuse to disable the possibility to disable the watchdog. Ever. Must have a reason :) ----- Ursprüngliche Nachricht ----- Von: Harri Haataja Gesendet am: 16 Mrz 2011 09:07:05 >> It took me quite some time (I had to dig into MSP assembly) to >> figure out that MSPGCC was silently disabling it. > I believe the least surprise is not doing magic things by default that > disagree with all the common documentation. I was certainly surprised > that this GCC does that. Yes, especially if it "changes" the specs of the device datasheet. For the compiler itself, well, if properly documented, this could be seen a little bit more relaxed. >> Indeed, this would work. But that's also 'advanced stuff'. >> Especially people who use the G line are newbies. >> Of course mspgcc could be promoted as 'expert stuff' not aimed at >> 'normal' MSP users but rather for experienced compiler-knowers, >> but I don't think this would be a good direction to go. >> Let's keep in mind that an MSP is no PC. So there is no point >> in desperately implementing things that are useless on an MSP >> 'just for conformity'. > Trying to guess at your audience instead of DTRT is a very rotten idea > IMO. Making things for your imagined "normal user" is probably what's > responsible for most of the user interface horrors out there. I partly agree. Yet there is no guessing about the target system. It is an MSP and no PC. So there is no reason for doing things PC-like as default when this is less performant/counterproductive for an MSP environment, while forcing people to learn compiler specifics to make things run right. I doubt anyone will try to directly compile a linux program or even an old DOS program for the MSP. Of course proper documentation is required for any implementation. And with 'proper' I don't mean a one-liner in the mspgcc source code, but rather an exhaustive explanation in a real manual that's available without Wiki, mailing list or digging through repository reports. I know from own experience that documentation usually is an orphan, as it does not push the code further. (well, sometimes it does, when you stumple over oddities while writing the documentation). However, it is vital for the success of a project, especially if things are not intuitive. JMGross ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
