2024-05-15 06:02 AM - edited 2024-05-15 06:02 AM
Hello all!
I am reaching out to see if anyone here has any experience jumping from application code to the embedded system bootloader while using the System Window Watchdog (WWDG) peripheral. I am using the STM32G431 series. The ST documentation (AN2606 Rev 62) has a fairly lengthy discussion on how to handle working with the IWDG peripheral, and I've avoided any issues using it, and then jumping. There is not, however, documentation on the WWDG. According to the manual, it seems like the only way to stop the WWDG is to do a system reset (just like IWDG)
So, it makes sense that if the system bootloader isn't petting the WWDG, then a direct jump to the bootloader would cause issues. I am just wondering if anyone has had success in performing this jump while using the WWDG peripheral.
I'm running the chip at 168MHz. WWDG is set up with a prescaler of 64 (on top of the 4096 baked into the peripheral). I am using WWDG as a standard watchdog, so the window value is set to its max 0x7F. The counter is reset to 0x7F. The jump to the bootloader is performed by
//Make our function to jump our program counter to the bootloader
SysMemBootJump = (void (*)(void)) (*((uint32_t *) SYSTEM_MEMORY_RESET_VECTOR));
//Make sure we shut everyone down
HAL_DeInit();
// Shut down any tasks running, kill interrupts, and Select HSI as system clock source
HAL_RCC_DeInit();
SysTick->CTRL = 0; // reset the Systick Timer
SysTick->LOAD = 0;
SysTick->VAL = 0;
__set_MSP(0x20004000);
// Load the program counter with the System Memory reset vector
SysMemBootJump();
//Should never get here
while(1){}
where SYSTEM_MEMORY_RESET_VECTOR is
// Memory address for SYSTEM_MEMORY_RESET_VECTOR = SYSTEM_MEMORY_STACK_POINTER_VALUE + 4
// For all STM32G4 series, this is 0x1FFF0000+4 = 0x1FFF0004, PDF Page 229 of AN2606
#define SYSTEM_MEMORY_RESET_VECTOR 0x1FFF0004
Without the WWDG enabled, this works just fine, and I can perform firmware updates via the system bootloader. When the WWDG is enabled, I can see the memory jump take place, and then the WWDG counter count down until reset which, obviously, kills the ability to complete the firmware update.
Just looking for any guidance/past experience to get through this bug. Thanks!
Solved! Go to Solution.
2024-05-15 02:37 PM
Dear @jleiber ,
I do not see how this can work in a reliable way. as the Watchdog window is designed at user application ( which varies from each case) it is not possible to fit the embedded code we put in our system bootloader which is mainly based on polling mechanism waiting for commands from host and then performing critical routines such as Flash programming by pages including the Erase operations. Timing is specified in AN2606 and Datasheet - Flash section. Au any time the WWDG can trig a reset when it fires the 7F period .
Cheers,
STOne-32
2024-05-15 02:37 PM
Dear @jleiber ,
I do not see how this can work in a reliable way. as the Watchdog window is designed at user application ( which varies from each case) it is not possible to fit the embedded code we put in our system bootloader which is mainly based on polling mechanism waiting for commands from host and then performing critical routines such as Flash programming by pages including the Erase operations. Timing is specified in AN2606 and Datasheet - Flash section. Au any time the WWDG can trig a reset when it fires the 7F period .
Cheers,
STOne-32
2024-05-15 02:41 PM - edited 2024-05-15 02:43 PM
Software-Reset the part and have it vector off to the System Loader's Reset_Handler as it enters yours, say by an expedited RAM variable/flag, and BEFORE you enable the WWDG..
2024-05-16 06:38 AM
I appreciate the replies! About what I was expecting, thank you!