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.

What is the best way on MSP430 to trigger a Reset (POR) by Software?

Other Parts Discussed in Thread: MSP430F2274, MSP430F5528

Hi Team,

I'm in the design phase of a small handheld device using MSP430F2274 or MSP430F5528. I like to reset the device in an exception case like power on. Which is the best way?

Shall I use a CPU instruction fetch as shown in example msp430x22x4_wdt_05.c?

    ((void (*)())0x170)();                  // Invalid fetch ("call #0170h")

Shall I connect a port pin with RST and active pull down?

Regards

Guenther

  • Guenther,

    You can cause a BOR or a POR in software for the 5xx devices now.

    See section 2.2.7 of the 5xx User's Guide for more details.

    Regards,

    William

  • Guenther Klenner said:
    Shall I connect a port pin with RST and active pull down?

    This is definitely a method that will alwas work :)

    depending on the device and the required level of reset (yes, there are different ones) there are other possibilities.

    You can:
    - enable the watchdog and make a while(1); This will cause a watchdog reset.
    - write to the WDT register (or other password protected modules) without usign the proper password. This will cause a password violation reset.
    - do a FLASH read (from RAM) while the flash controller is busy writing (this will cause an access violation reset)

    On the 54xx devices, the PowerManagementModule (PMM) provides some bits for simulating a RESET:
    - the PMMSWBOR bit, if set manually, will do exactly the same as a brownout (power-off), awaking from LPM4.5 (former LPM5) or pulling the RESET line: a BOR (BrownOutReset event), except that you can read in the RESET vector register what caused the reset. Everything else is initialized, including the Supply voltage supervisor.
    - the PMMSWPOR bit, if set mahually, will trigger a POR (PowerOnReset) which is what happens if the Supply Voltage Supervisor has detected over- or undervoltage. A POR is also causde by a BOR. Only that the SVS itself isn't reset if it is just a POR.

    All other reset events, inlcuding the watchdog and a POR, will cause a PUC (PowerUpCondition), which initializes almost all of the hardware except of the PMM and the SVS. You can see in the family users guide, which register bits are initialized to what and whether it happens at a PUC, a POR or a BOR only.

  • Hello Jens-Michael,

    Thank you for the hint on the WDT register. I guess this is a way which works on both MCUs.

    The addition on the MSP430F5xxx is interresting and opens other oportunities.

    For all other users in similar situation: Please be aware a call of reset vector does not reset HW register and modules. I hope you do not make the same experiance as I did on an I2C exception case.

    Thank you all (Jens-Michael and  William) for the prompt response

    Guenther

  • Guenther Klenner said:
    Thank you for the hint on the WDT register. I guess this is a way which works on both MCUs.


    It does. I used it on 1232 and 1611. One just has to keep in mind that not everything is reset by a WDT reset. The voltage supervisors, for example, aren't. and also some configuration bits of the hardware aren't reset too.

    And yes, you're right, calling the reset vector just resets the software/CPU part of the MCU and does not touch anything else. Most important: it keeps all currently running interrupt sources alive. Including pending interrupts, communication status etc.

  • Hi,


    The _disadvantage_ of the WDT way is that you loose the diagnostic at reset time. If your application want to signal the reason for the reset as an diagnostic flag/signal you can't use this method as you may not be able to distinguish between a real Watchdog event and a reset via the WDT.


    Further more the WDT event does not touch any IO registers (no POR).

    What I do to get the device to start at  reset is the following code (non POR)

    void ColdStart(void)
    {
    // start the code from reset, never returns
        dint();
        WDTCTL = WDTPW | WDTHOLD;   
        asm ("push &0xfffe");
        asm ("ret");                                                           // return from function does a reset (redundant)
    }

    Kees

    Kees

  • To restart the controller I always used the violation of the WDT password by writing

    WDTCTL = 0xDEAD;

  • You can set a flag somewhere that tells whether the WDT reset was a real WDT reset or a forced one. You can pick any of the registers that are initialized at BOR but not at PUC.
    Your method is good for restarting the program, but it does not reset any hardware register, while a PUC will initialize much (but not all). This may cause problems if the program flow expects (or unintentionally requires/assumes) some default values when setting-up the hardware (like the current CPU speed/clock settings).

  • Dennis Eichmann said:
    WDTCTL = 0xDEAD;

    If there is a Like button, I would have pressed it!

    Anyways, you can also do the following

    PMMCTL0 = PMMPW | PMMSWBOR;   // This triggers a Software BOR

    PMMCTL0 = PMMPW | PMMSWPOR;   // This triggers a Software POR

  • I too like the WTDCTL = 0xDEAD; :)

    However, the software BOR/POR is only available on devices with PMM. Which means 5x family and later. The WDT, while being limited, also works on 1x to 4x family.

**Attention** This is a public forum