Issues with the independant watchdog

[p0ulp3]

Posted on April 29, 2010 at 16:06

Issues with the independant watchdog

[domen23]

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]

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]

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]

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

[Tesla DeLorean]

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.

[brianeley9]

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