The ota2 bootloader functions as below:
It checks if the reset was due to Watchdog? If its a WDT reset, it checks if there is a valid image in the staged area. If there is a valid image, it sets up the boot type to extract from staging area(OTA2_BOOT_FAILSAFE_UPDATE ) and runs failsafe app and OTA2 extract app. Hence the valid image from staged area is loaded. If there is no valid image in staged area, (boot type is set to OTA2_BOOT_FAILSAFE_ FACTORY_RESET ) the factory reset image is loaded.
To answer the use case mentioned in this thread:
The boot type variable takes care of the reset condition. If the reset has occured due to WDT, the failsafe app always comes into picture as it is not the normal behavior under which the reset occurred(i.e., NOT POR). The failsafe is responsible to extract the application LUT and ota2_extract to allow full extraction on reboot.
The queston is if application hangup can cause WDT reset or not.
If yes, it will switch to failsafe app. This seems quite surprising behavior.
Correct, while a WDT is not included by design, given the sheer compelxity of a Wi-Fi base dproject with the stack and FreeRTOS it is a given that we may encounter a WDT in normal operation.
I have seen the failsafe app become corrupted after an OTA update due to the build size of the failsafe app and how external flash is sectioned, see my other post "CYW43907/1GC fails up boot after update".
So if a random WDT in the application resets the processor and the failsafe app runs then it is possible to have a bricked system because the failsafe app is corrupted.
There is no way to update failsafe and bootloader in a device which is out in the field.
We have increased the failsafe application size in image defines to 100KB to address this problem in future. Really sorry for the inconvenience.