cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with the independant watchdog

p0ulp3
Associate II
Posted on April 29, 2010 at 16:06

Issues with the independant watchdog

6 REPLIES 6
domen23
Associate II
Posted on May 17, 2011 at 13:49

And what's the value of DBG_IWDG_STOP?

Alternately, you could just detach the debugger, and see if it works then.
p0ulp3
Associate II
Posted on May 17, 2011 at 13:49

Hi,

the register CR of DBGMCU is at 0, so the bit DBG_IWDG_STOP is at 0 (0: The watchdog counter clock continues even if the core is halted, based on the datasheet).

I had also tried to remove the debugger but without any success.

By looking at the interrupt vector in the datasheet, I can see that there are the Non Maskable Interrupt, the IWDG interrupt, Hardfault Interrupt, and all the maskable interrupts with configurable priorities.

My question is, if there is a non maskable interrupt, can we say that the IWDG is a maskable interrupt ? and if so, where can I enable this interrupt ?

Regards

domen23
Associate II
Posted on May 17, 2011 at 13:49

Huh, dunno, maybe this helps you. I use it to start the watchdog with max timeout (about half a minute at 64 MHz).

static void watchdog_init()

{

    if (RCC_GetFlagStatus(RCC_FLAG_IWDGRST))

        printf(''there was a watchdog reset\n'');

    /* lets not ClearFlag, because rtc init does it for us */

    IWDG_WriteAccessCmd(IWDG_WriteAccess_Enable);

    /* 0xfff*256/(30..60)khz -> 17-35s */

    IWDG_SetPrescaler(IWDG_Prescaler_256);

    IWDG_SetReload(0xfff);

    IWDG_ReloadCounter();

    IWDG_Enable();

    /* stop watchdog when core is stopped (debugging) */

    DBGMCU_Config(DBGMCU_IWDG_STOP, ENABLE);

}

p0ulp3
Associate II
Posted on May 17, 2011 at 13:49

Hi Domen,

thanks for your reply, basically the example that I use is very similar :

  /* IWDG timeout equal to 280 ms (the timeout may varies due to LSI frequency

 

     dispersion) */

 

  /* Enable write access to IWDG_PR and IWDG_RLR registers */

 

  IWDG_WriteAccessCmd(IWDG_WriteAccess_Enable);

 

 

  /* IWDG counter clock: 40KHz(LSI) / 32 = 1.25 KHz */

 

  IWDG_SetPrescaler(IWDG_Prescaler_32);

 

 

  /* Set counter reload value to 349 */

 

  IWDG_SetReload(349);

 

 

  /* Reload IWDG counter */

 

  IWDG_ReloadCounter();

 

 

  /* Enable IWDG (the LSI oscillator will be enabled by hardware) */

 

  IWDG_Enable();

 

DBGMCU_Config(DBGMCU_IWDG_STOP, ENABLE);

 

 

  while (1)

 

  {}

 

Do you had any special configuration to do before launching the IWDG ? some IT to enable for example ?

Regards

Posted on May 17, 2011 at 13:49

As a side note, forcing the reset pin high was also preventing software resets from working correctly.

 

Yeah, seen that before, hope you didn't waste too much time. Usually someone driving a -RESET pin with a push-pull driver rather than an open-collector/drain one.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
brianeley9
Associate
Posted on May 17, 2011 at 13:49

Hi,

I experienced the exact same symptoms and it turned out that the watchdog could not reset the STM32 because an external power monitor chip was forcing the reset pin high. I disconnected the power monitor chip so that the only thing tied to the micro's reset pin was a 10K pull-up resistor, and the watchdog was suddenly able to reset the processor exactly as expected.

As a side note, forcing the reset pin high was also preventing software resets from working correctly.

Hope this saves someone the pain I went through,

Brian