• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 365 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.

CCS/RF430FRL152H: RF430FRL152HEVM WatchDog

Allen Chen 3
Prodigy 230 points
Part Number: RF430FRL152H
Other Parts Discussed in Thread: MSP430L092

Tool/software: Code Composer Studio

Hi,

I would like to implement watchdog to controlled system restart after software problem occurs.

But it have no interrupt in WDT_ISR.

I have some questions as below:

1. How can I test the system stuck and prove the watchdog is working properly.

2. Can be written reset information to FRAM when watchdog occurs? (After system reset it can read the reset reason from NFC)

Thanks.

========================================================================

WDTCTL = WDTPW | WDTIS2 | WDTCNTCL | WDTSSEL0;
SFRIE1 = WDTIE;

...

static u32_t wdtIdx = 0;
#pragma vector = WDT_VECTOR
__interrupt void WDT_ISR(void)
{
wdtIdx++;
}

=========================================================================

  • 0
    TI__Mastermind 18265 points

    Hello Allen,

    the WDT has two modes. The watchdog mode and the interval timer mode.

    In watchdog mode a PUC (reset) is generated and no interrupt. In interval timer mode an interrupt is generated.

    You have selected the watchdog mode and so no interrupt occurs.

    Best regards,

    Helfried

  • 0 in reply to Helfried Vollbrecht
    Prodigy 230 points

    Hi Helfried,

    In normal case, we will reset the FRAM data when system boot.

    And write some data in FRAM if the system is working normally.

    But we need keep the FRAM data after watchdog reset occurs.

    Can we know from other registers whether it is a normal system restart or watchdog reset?

    Thanks.

  • 0 in reply to Allen Chen 3
    Prodigy 230 points

    Hi Helfried,

    Have any update for this question?

    Thanks.

  • 0 in reply to Allen Chen 3
    Guru 92251 points

    Allen Chen 3 said:
    Can we know from other registers whether it is a normal system restart or watchdog reset?

    The SYSRSTIV Register can be read to identify the last cause of a Reset.

    Note that there might be multiple pending interrupt flags, and so the SYSRSTIV register should be read until returns zero,

  • 0 in reply to Chester Gillon
    Prodigy 230 points

    Hi Chester,

    I add breakpoint at the start of main function.

    After WatchDog reset, it will stop at this breakpoint.

    But I check the SYSRSTIV register value is 0x0002.

    How can I get the WDT time-out (PUC) information? After reset or before reset?

    Thanks.

  • 0 in reply to Allen Chen 3
    Guru 92251 points

    Allen Chen 3 said:
    But I check the SYSRSTIV register value is 0x0002.

    The SYSRSTIV register can return the following values as described in the RF430FRL152H datasheet:

    The SYSRSTIV register can have multiple reset sources pending, and returns the pending reset sources in priority order.

    A SYSRSTIV value of 0x0002 is for Brownout and is a valid value.

    Allen Chen 3 said:
    How can I get the WDT time-out (PUC) information? After reset or before reset?

    After a reset, but you have to read SYSRSTIV in a loop until it returns SYSRSTIV_NONE (0). There might be multiple reset sources recorded.

    E.g. by using code of the following form at the the start of your code:

    int num_reset_causes_unknown;
int num_reset_causes_bor;
int num_reset_causes_svmbor;
int num_reset_causes_rstnmi;
int num_reset_causes_dobor;
int num_reset_causes_secyv;
int num_reset_causes_dopor;
int num_reset_causes_wdtto;
int num_reset_causes_wdtkey;
int num_reset_causes_ccskey;
int num_reset_causes_pmmkey;
int num_reset_causes_perf;

int main(void)
{
    bool reset_causes_read = false;
    do
    {
        switch (SYSRSTIV)
        {
        case SYSRSTIV_NONE:
            reset_causes_read = true;
            break;

        case SYSRSTIV_BOR:
            num_reset_causes_bor++;
            break;

        case SYSRSTIV_SVMBOR:
            num_reset_causes_svmbor++;
            break;

        case SYSRSTIV_RSTNMI:
            num_reset_causes_rstnmi++;
            break;

        case SYSRSTIV_DOBOR:
            num_reset_causes_dobor++;
            break;

        case SYSRSTIV_SECYV:
            num_reset_causes_secyv++;
            break;

        case SYSRSTIV_DOPOR:
            num_reset_causes_dopor++;
            break;

        case SYSRSTIV_WDTTO:
            num_reset_causes_wdtto++;
            break;

        case SYSRSTIV_WDTKEY:
            num_reset_causes_wdtkey++;
            break;

        case SYSRSTIV_CCSKEY:
            num_reset_causes_ccskey++;
            break;

        case SYSRSTIV_PMMKEY:
            num_reset_causes_pmmkey++;
            break;

        case SYSRSTIV_PERF:
            num_reset_causes_perf++;
            break;

        default:
            num_reset_causes_unknown++;
            break;
        }

    } while (!reset_causes_read);

    I don't have a RF430FRL152H at the moment, but tested the above code in a MSP430L092 which can return the same SYSRSTIV values as a RF430FRL152H.

    The code showed:

    a. The first time a debugged a program after connect the device connected to a MSP-FET430UIF recorded a SYSRSTIV_BOR and then a SYSRSTIV_RSTNMI.

    b. The second time debugged the program, leaving the device connected to a MSP-FET430UIF recorded just a SYSRSTIV_RSTNMI.

  • 0 in reply to Chester Gillon
    Prodigy 230 points

    Hi Chester,

    After add read SYSRSTIV in a loop, it is work.

    Thank you so much.