• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 2070 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Why is setting PMMCOREV necessary for SW POR reset?

Vern Yip
Intellectual 810 points
Other Parts Discussed in Thread: MSP430F5659

So originally I tested my watchdog timer which resets the device:  PMMCTL0 = PMMPM + PMMSWPOR;


however, once I changed the V(CORE) level to level 3, I noticed that when doing a POR again using the above register settings, the MSP430 locked up.  Upon inspection, I noticed the PMMCTL0 register has options to also set the PMMCOREV.  So it sounds like I also need to define the CORE voltage for the watchdog when issuing a software POR ?

Once I did this, my code became: PMMCTL0 = (PMMCTL0&0x3) + PMMPW + PMMSWPOR;


Why is it that I need to do this ?? 

  • 0
    TI__Guru 68116 points

    Hi Vern,

    I think your problem is this:

    If you are running your code with Vcore level 3 before the reset, your PMMCTL0 register contains a value with the last two bits set (for PMMCOREV_3). Now, if at this point you use the instruction you mentioned: "PMMCTL0 = PMMPM + PMMSWPOR;" This is going to clear those last two bits, setting PMMCOREV = 0. However, you should never change Vcore more than one level at a time - see section 2.2.5 Decreasing Vcore in the 5xx/6xx user's guide www.ti.com/lit/pdf/slau208

    So what is happening is the code is setting it straight from Vcore level 3 to Vcore level 0 rather than stepping down 1 level at a time - this can cause serious problems as you saw.

    So your code you posted will work. Another option would be to not use "=" but rather to set only the PMMSWPOR bit while retaining the other bits in the register. You would need to first set the password in the upper byte of PMMCTL0 and then could do a byte write to the lower PMMCTL0 register to set only PMMSWPOR using |=. Something similar to this:

    PMMCTL0_H = PMMPW;
PMMCTL0_L |= PMMSWPOR; //set SW POR, while retaining PMMCOREV setting

    This is probably a better way, because then the code does not need to know what Vcore setting you had in there previously so this code could be reused even if the level was not level 3 when this SW POR needs to happen - it will always make sure the core level is retained.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Intellectual 810 points

    Hello Katie

    Your assumptions are correct.  This seems to be the problem I was having since once i issued the POR, I also stepped the voltage down to level 0. This caused it to lock up.


    Thanks

  • 0 in reply to Katie Pier
    Prodigy 50 points

    Hi Katie,

    I am working with a MSP430F5659 in an eval board. 

    As you suggested above,

    PMMCTL0_H = PMMPW_H;
PMMCTL0_L |= PMMSWPOR; //set SW POR, while retaining PMMCOREV setting

    does cause a POR, and I can cause just a PUC with:

    PMMCTL0   |=  PMMPW ^ 0xFFFF; /* Bad password with word write preserving VCORE */

    but I am trying to generate a BOR using

    PMMCTL0_H = PMMPW_H;
PMMCTL0_L |= PMMSWBOR; //set SW BOR, while retaining PMMCOREV setting


    without success. It does nothing. I think the problem is the fact that I have a MSP-FET430UIF debugger and IAR IDE attached to the JTAG lines?
    It's a bit hard to tell with just an eval board, but I thing BOR is happening if I unplug the debug dongle.  I can trap POR and PUC in the IAR debugger, but not the BOR. 

    Is there a way allow a BOR to be generated, and trapped, with the debugger attached?

  • 0 in reply to John D
    TI__Guru 68116 points
    Hi John,

    I think it is best to test resets without the debugger connected if possible. If you are trying to observe the BOR happening, you may want to add a line to the beginning of your code that reads SYSRSTIV into a variable, and then does a GPIO toggle a number of times to represent the value of that variable or something - then you can observe on an LED, scope, or logic analyzer. That will make it observable even if you can't put a breakpoint to catch it. I don't know if you've already tried this, but did you try doing "free run" in IAR? I don' t know if this will then hit a breakpoint later if you do that though...

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 50 points

    Hi Katie,

    Thanks for the reply. Your suggestion was a good one.  Using a strobe and my Salaea Logic scope, I was able to cause and verify PUC, POR, and BOR. Both PUC and POR work fine with the IAR Debugger attached to JTAG via TI MSP-FET430UIF dongle.  BOR works only sporadically with the debugger attached, which I find odd, shouldn't it always fail or always work? Anyway, detaching the debugger from the target with the "big red X", but leaving the dongle attached, is sufficient to make BOR perform reliably.  I was able to strobe the appropriate values from SYSRSTIV, 0x02 (BOR), 0x14 (POR), and 0x20 (PUC), and was able to verify different levels of register bit reinitialization, i.e. -0 vs. -(0) vs. -[0] in the Users Guide's nomenclature. Thanks!

**Attention** This is a public forum