Yes. You are correct. You can see this piece of code in our Bootloader/DFU code examples in PSoC Creator.
* In the case of non-software reset check if there is a valid app image.
* If these is - switch to it.
if (Cy_SysLib_GetResetReason() != CY_SYSLIB_RESET_SOFT)
status = Cy_DFU_ValidateApp(1u, &dfuParams);
if (status == CY_DFU_SUCCESS)
* Clear the reset reason because Cy_DFU_ExecuteApp() performs a
* software reset. Without clearing it, two reset reasons would be
}while(Cy_SysLib_GetResetReason() != 0);
/* Never returns */
Thanks for your response.
Does that mean that there is no way to handle the reset flags in the main? That it has to be cleared in the bootloader?
I'm asking because it would be nice if the main app could know the reason for the reset and possibly log it in our system log. If the bootloader has to clear the flag, then the main app will never know that the watchdog caused a reset.
(We are using Modus Toolbox 2.1 and no HAL)
1 of 1 people found this helpful
>>"Does that mean that there is no way to handle the reset flags in the main? That it has to be cleared in the bootloader?"
--> I can suggest you a workaround to overcome this drawback. You can use the device User SFLASH to store the custom data. In the bootloader appication before clearing the Reset reason, the user can store the the information of the reset reason to SFLASH.
Please go through the following KBA:
You can also use Flash write and Flash read APIs instead of creating a separate section as mentioned in the above KBA.
Hope this helps !