 Hello, my name is André Barata and I would like to welcome you to the dedicated session of the Windows Watchdog timer from the STM32L4 MOOC training. Watchdog timers in general are used to recover the microcontroller from software anomalies. This software anomalies causes the program to abandon its normal sequence and hanging in inesporate states. This self-recovering feature is particularly useful in applications which cannot be monitored by a human operator or which cannot wait for the operator to reboot the system to meet the time requirement for the products. WWDG stands for Window Watchdog. This peripheral is named after its unique feature of just allow being refreshed within a defined time window. The objectives of this session are to learn how to set up Window Watchdog in the STM32 Cubemix and to refresh it in the code. We will also learn how to identify the root problem that caused the program to hang. To accomplish these objectives we will need to go through four steps. The first will be to configure the Window Watchdog and the GPIOs in the STM32 Cubemix. We will generate the code and already in the system workbench for STM32 we will refresh the Window Watchdog on a regular basis. The third step will be to simulate a software failure to verify the recovery mechanism that we are trying to implement. And the fourth and the last will really include the verification method to check if the Window Watchdog reset flag was set. The Window Watchdog is clocked from the APB clock bus which is derived directly from the system clock. This means whenever MCU is in a low power mode except for sleep mode there is no need to refresh the Window Watchdog as it is not being clocked. While using the Window Watchdog it is important to refresh it before entering the low power mode. In fact, this is a good practice as we are preventing it to reach its limit during the wake up phase of the MCU and therefore preventing unwanted resets. Here we can see the Window Watchdog block diagram. The system reset is triggered when the most significant bit of the counter is cleared. There is also a system reset whenever the Window Watchdog is refreshed to early. This means in situations where the counter is refreshed while the window value is smaller than the counter value. As you might recall from the previous slide the Window Watchdog is clocked directly from the APB bus and then goes through a fixed pre-scaler and a programmable pre-scaler. To calculate the maximum Window Watchdog timeout we would have to consider 127, the maximum value that the counter can assume, minus 40 in hexadecimal. We would realize that we have 64 ticks before the reset. By computing the default values on the Window Watchdog timeout formula we can see that the maximum timeout is roughly 65 ms. For the purpose of our application we are going to refresh it every 22 ms. Before switching to the STM32 Cuba Mix to start generating code we will take a moment to analyze the Window Watchdog hands-on float chart. This float chart will make our implementation easier and probably clearing the doubts you were having. The program starts on the reset state and we will proceed to initialize our peripherals. We will verify if the Window Watchdog reset flag is set since this is the first time we are running the program it should be cleared. Then we will enter an infinite loop where an LED is being toggled with a pre-dc t lower than the max timeout value of the Window Watchdog timer, which means that in every cycle we will be able to refresh the Window Watchdog. So the infinite loop will go on and on until a moment where a user would press a button and this will trigger an external interrupt. In this service call routine we will attempt to write an invalid address which will lead the MCU to generate a hard fault. If Window Watchdog would not be implemented the MCU would get stacked here until someone would externally reset it. After the Window Watchdog timeout is met the program will reset itself and after initialization of the peripherals once more we would check for the Window Watchdog reset flag and in this case the flag should be set which will indicate that the system got reset during its execution. A red LED would be turned on which indicates the user that the system was reset. So without further ado let's launch our STM32 QBMX, let's configure the Window Watchdog, let's configure the GPIOs to help us generating N2GAL LEDs. On during our code we will refresh the Window Watchdog timer, on the service call routine as you recall we will need to generate a failure and we will need to make our verification if the Window Watchdog reset flag was set and if yes the red LED should be turned on. With the STM32 QBMX open we will start a new project, we will type the part number STM32 L476VG, we will start a new project, we will start by initializing the GPIOs connected to the LEDs which in this case will be PE8 for the green LED and PB2 for the red LED. We are going also to initialize PA0 for the external interrupt, so whenever we would press the central button of the joystick in our discovery board we will enter the interrupt mode, we will need to activate the Window Watchdog. In our clock configuration we are going to leave it everything in the standard configuration. Now we go to the configuration tab, GPIOs we are going to leave it in default, in the end week we need to activate the external interrupt line. On the Window Watchdog configuration we will set the down counter to its maximum value, so for 7 bits this will mean 127. Since we won't make use of the window feature in this example we will also set it to its maximum, the prescalar we will leave it as default. We will apply and now before generating the code we will need to save our project and give it an appropriate name. Do never forget to select the proper IDE which in our case continues to be the System Workbench for STM32, so now we are ready to generate the code. Then we will just need to open the project to automatically open our System Workbench for STM32. After the code is generated by STM32 QPMX we can see that all our peripherals were initialized. In the GPIO configuration we can see that the clocks have been enabled, PA0 is defined as input combined with external interrupt capability and sensitive to rising edge. The two other GPIOs have been configured as output to drive the LEDs. The window watchdog configuration has been configured according to the STM32 QPMX input parameters. We will start by toggling the green LED to signalize that we are in the infinite loop. After we will add 22 milliseconds of delay before refreshing the window watchdog counter. The HAL window watchdog refresh function has only one input parameter which is the pointer to the device handler. We will include a verification to be preformed every time the program runs with which checks if the window watchdog flag was set. If the flag was set the red LED will be turned on meaning a program reset happened caused by the window watchdog. To finalize this step we will clear all reset flags. Now we need to go to the interrupt handle which can be found in source STM32L4XXIT. On the bottom of the file we will find XT0 handler and we will write to an invalid address. Writing to an invalid address will result on the hard fault exception. After building and launching the program you will see the green LED toggling endlessly. To the moment you press the joystick center key and the red LED will also be turned on. This will notify the user for a window watchdog system reset. Thank you for watching.