IWDG and WWDG in STM32

In this tutorial, we will see how to use IWDG (Independent Watchdog) and WWDG (Window Watchdog) in STM32. Both of these watchdogs are used for similar purpose, but the difference is in their implementation. The major difference between the two is Independent Watchdog can be reset at any time before the timeout occurs, but the Window Watchdog can only be reset in a particular window of time.

This tutorial will be covered into two halves. The first half will cover the IWDG, and the second will cover WWDG. So let’s start with the first one now

IWDG

  • The independent watchdog is used to detect and resolve malfunctions due to software failures. It triggers a reset sequence when it is not refreshed within the expected time-window.
  • Since its clock is an independent 32-kHz low-speed internal RC oscillator (LSI), it remains active even if the main clock fails.
  • Once enabled, it forces the activation of the low-speed internal oscillator, and it can only be disabled by a reset.
  • One of the main benefits for applications is its ability to run independently from the main clock.

Setup

The CubeMX setup is shown below

iwdg setup

As you can see above, there are two parameters that we need to input i.e. the Prescalar and the Counter values. These values will decide the Reload Time for our application. To decide these values, there is a formula provided by ST as shown below

iwdg formula by ST

Reference : – https://www.st.com/content/ccc/resource/training/technical/product_training/group0/01/24/22/29/38/70/40/57/STM32WB-WDG_TIMERS-Independent-Watchdog-IWDG/files/STM32WB-WDG_TIMERS-Independent-Watchdog-IWDG.pdf/_jcr_content/translations/en.STM32WB-WDG_TIMERS-Independent-Watchdog-IWDG.pdf


The above formula can be a bit confusing. I have modified this to make it a bit more simple, and the explanation of the terms used is shown below

iwdg formula modified

The formula shown above is explained below

  • RL is the Counter value, that we need to put in the setup
  • Time is the timeout value (in ms) for the watchdog. If the counter is not refreshed before this time, the system will reset
  • PR is the prescalar and the values are as shown below
iwdg prescalar

Let’s take an example, if i want to set the Timeout of 20 ms.

  • I decided to choose the Prescalar as 8. So PR = 1
  • If we substitute these values in the above formula, we will get the RL = 79.
  • So we need to substitute counter value = 79 in our setup.
  • If the RL value goes higher than 4095, then you need to increase the prescalar.

Code explanation

int main(void)
{

  HAL_Init();

  SystemClock_Config();
  
  MX_GPIO_Init();

  HAL_Delay (500);
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, 1);

  MX_IWDG_Init();

  while (1)
  {
    HAL_Delay (18);
    HAL_IWDG_Refresh(&hiwdg);

  }
}
  • MX_IWDG_Init (); Initializes the IWDG.
  • Note that I have turned on the LED before initializing the watchdog. This will provide a blinking effect, if the system resets and the execution starts from the beginning
  • But as I am refreshing the counter after 18 ms (Timeout being 20 ms), the system will never reset, and the while loop will keep executing forever
  • In the above case, The LED will always be ON

You can check the video at the end of this post, to see the working.

This is it for IWDG, the next part will cover the WWDG.






WWDG

  • The window watchdog is used to detect the occurrence of software faults.
  • It can be programmed to detect abnormally late or early application behavior.
  • It is best suited for applications required to react within an accurate timing window.
  • Once enabled, it can only be disabled by a device reset.

Basically, here we have a time window, within which we can refresh the counter. If we try to refresh it outside that window, the system will reset.

Setup

wwdg setup

As shown above, we have 3 parameters to set. They are prescalar, the window value, and the downcounter value. Let’s first see the formula provided by ST to handle this

wwdg formula by ST

Reference:- https://www.st.com/content/ccc/resource/training/technical/product_training/group0/7b/5b/71/88/b9/64/48/d6/STM32WB-WDG_TIMERS-System-Window-Watchdog-WWDG/files/STM32WB-WDG_TIMERS-System-Window-Watchdog-WWDG.pdf/jcr:content/translations/en.STM32WB-WDG_TIMERS-System-Window-Watchdog-WWDG.pdf


The above formula sure a bit confusing as it doesn’t really show us the maximum and the minimum time. I have modified this, and came up with somewhat simpler formula as shown below

wwdg formula modified

The formula is explained below:

  • WWDG is connected to the APB1 bus, and therefore derives it’s clock from APB1 CLOCK
  • COUNTER value is the value for downcounter.
  • This value is related to the MAX TIME (in ms) of the timeout window
  • WINDOW is the window value in the setup, and related to the MIN TIME (in ms) of the timeout window
  • PR is the prescalar in the setup, and the values are as shown below
prescalar wwdg

Let’s Take an example, where I want the timeout window in between the 13 ms – 20 ms. To do this calculation, the steps are as provided below

  • First, do the calculation for COUNTER value, as it is required to calculate WINDOW value
  • I am choosing the prescalar as 4, so the PR = 2
  • After substituting the required values in the 1st formula, I got the COUNTER = 119. Here APB1 CLOCK = 45 MHz, and MAX TIME = 20
  • using this COUNTER value, and MIN TIME = 13, we can find the WINDOW value
  • WINDOW = 83
  • We need the substitute these values in our setup i.e. Prescalar = 4, Window = 83, and Downcounter = 119
  • Keep in mind that the min and max values for Window and Downcounter are 64 and 127. So if you are getting the values higher or lower than these, you need to reduce or increase the prescalar respectively.

Code explanation

int main(void)
{

  HAL_Init();

  SystemClock_Config();
  
  MX_GPIO_Init();

  HAL_Delay (500);
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, 1);

  MX_WWDG_Init();

  while (1)
  {
    HAL_Delay (15);
    HAL_WWDG_Refresh (&hwwdg);
  }
}

The above code works as follows

  • MX_WWDG_Init (); Initializes the WWDG.
  • Note that I have turned on the LED before initializing the watchdog. This will provide a blinking effect, if the system resets and the execution starts from the beginning
  • But as I am refreshing the counter after 15 ms (Window being 13 ms – 20 ms), the system will never reset, and the while loop will keep executing forever
  • In the above case, The LED will always be ON
  • One thing to keep in mind here is that, if I try to reset the counter in 10 ms (<13 ms) or 22 ms (>20 ms), the system will keep resetting and the LED will keep blinking.


Result

Check out the Video Below










Info

You can help with the development by DONATING
To download the code, click DOWNLOAD button and view the Ad. The project will download after the Ad is finished.

9 Comments. Leave new

  • Great explanation!
    The IWDG modified formula is wrong. it supposed to be,
    RL = ((Time x 32000) / (4 * 2^PR)) – 1

    Reply
  • Note, the formula for IWDG (RL calc) does not meet the times reported in document RM0090 for STM32F4.

    Reply
  • I have tried running same program using different values of prescalar for same time but the leb neither glows nor blinks please upload more videos related to stm32

    Reply
  • Thanks for this tutorial.
    With my stm32f103c8t in the cubeIDE clockConfiguration module the LSI RC clock is 40kHz (not changeable). So that is the basis for my watchdog timing.
    Just for information, that it is not automatically 32kHz to calculate with. Don’t know what influences the LSI RC speed, if it’s stm32 family dependent or something…

    Reply
    • If you look at the second picture in the IWDG, it clearly defines the use of LSI.
      Since the F103C8 have 40Khz, I guess instead of 32000, you should use 40000.
      I haven’t tried it, but let me know the result.

      Reply
      • Well, I use prescaler 128 and reload 4095. With 32kHz this should give me 16,4s watchdog timeout. With 40kHz it results in 13,1s timeout.
        And what do I “measure” (with LED turning off and on and stop watch)? 14 seconds, which is more like 13s than 16s. But 1s difference is far beyond my reaction time.
        Maybe the internal clock is not that precise, or something from the startup takes some time. I also tried with reduced prescaler, instead of calculated 6,5s I measure 7s and instead of 3,3s timeout I get 3,5s… so some proportional problem.

        Reply
  • you are very good guy. thanks for sharing your knowledge.

    Reply
  • Thanks again.

    Reply
  • Muhammad Usman
    October 31, 2020 1:02 PM

    Great Work !

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

keyboard_arrow_up

Adblocker detected! Please consider reading this notice.

We've detected that you are using AdBlock Plus or some other adblocking software which is preventing the page from fully loading.

We don't have any banner, Flash, animation, obnoxious sound, or popup ad. We do not implement these annoying types of ads!

We need money to operate the site, and almost all of it comes from our online advertising.

Please add controllerstech.com to your ad blocking whitelist or disable your adblocking software.

×