----- Ursprüngliche Nachricht ----- Von: Peter Bigot Gesendet am: 25 Aug 2011 21:51:31
> On Thu, Aug 25, 2011 at 2:26 PM, M. Andree > <mand...@mail.uni-paderborn.de> wrote: > > No. If you poke something into WDTCTL that does NOT contain WDTPW in the > > proper position, the nodes are going to do a POR (power-on reset). It's > > a bit less than a PUC you get after powering up, and can cause other > > nasty effects (been there had those)... and documented behaviour. > What you said isn't quite right: a WDT violation does do a PUC, but > not a POR. A PUC doesn't really clear everything that a POR does. > Peripheral register configurations are left in place, and I believe > some interrupts may remain pending. Not a good state to be in. Still not entirely correct: There are three different reset stages: First is BOR. (Brown-Out Reset). It is triggered by power-on, brownpout or RST pin. It resets any voltage supervisor and any reset vector register (if present) and then does a POR. Next is POR (Power On Reset). It resets some of the hardware modules, such as the timers, but not the voltage supervisor and does nor clear the reset vector register. And I _think_ that in this state the CPU is reset too. (it makes sense to reset the CPU when the SVS triggers a reset. However, a POR does not enter the BSL entry check) Then it does a PUC. Last is PUC (Power-Up-Condition). It resets the remaining hardware. Whether a register (or a register bit) is reset by PUC, POR or BOR can be detected by the brackets around the register initial values. No brackets mean 'reset on PUC', while round brackets mean 'reset by POR' and curled ones indicate 'reset only by BOR'. One should keep in mind that the timer registers are NOT reset on a PUC. Any enabled timer interrupt is still enabled (but GIE is clear), so there might be interrupts pending which trigger as soon as GIE is set. Also, the timer counter is not reset. So it's best to init all the hardware you ever use in your code, before setting GIE. Then you can be sure that it is in a known state, even if the system is being reset unintentionally by a violation. The missing reset on the timers, however, might be useful in some situation where you want to keep track of the time even if restarting the software for some reason. On devices without SVS, BOR and POR are identical. > If your MCU supports it (the feature is in the 5xx family at least), > this suggestion from > http://tech.groups.yahoo.com/group/msp430/message/48258 is way better > than trying to manually put everything back to POR state. > PMMCTL0 |= PMMSWPOR; It's a new feature in the 5x/6x Family and part of the newly introduced power management module. And it is a better way than connecting the RST pin with a port pin to cause a 'real' reset :) On previous families, the suggested method (besides the mentioned port pin method) was to write something into the WDT register and cause a password violation reset. It is at least a bit better than just jumping through the reset vector. JMGross ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
