Can't switch app if WDT_RESET bit is set in RES_CAUSE

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
user_4631386
Level 1
Level 1
First question asked First reply posted

Our application consists of a main app and a bootloader/DFU.

We are using the watchdog timer in the main app. When the watchdog causes a reset, we get stuck in the bootloader/DFU unless the WDT_RESET bit is cleared in RES_CAUSE register by either

SRSS_RES_CAUSE = 0x00000001U;

or

Cy_SysLib_ClearResetReason();

I inspected the code and found that the bootloader/DFU goes all the way into Cy_DFU_ExecuteApp, sets the app ID and calls CySoftwareReset. But if the WDT_RESET bit is set, it always "wakes up" as the bootloader/DFU.

Is that intentional or have I missed something? I was hoping that we didn't have to deal with the watchdog in the bootloader/DFU, and could clear the bit in the main app.

0 Likes
1 Solution
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi,

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

            * present.

            */

            do

            {

                Cy_SysLib_ClearResetReason();

            }while(Cy_SysLib_GetResetReason() != 0);

            /* Never returns */

            Cy_DFU_ExecuteApp(1u);

        }

    }

Thanks

Ganesh

View solution in original post

0 Likes
3 Replies
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi,

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

            * present.

            */

            do

            {

                Cy_SysLib_ClearResetReason();

            }while(Cy_SysLib_GetResetReason() != 0);

            /* Never returns */

            Cy_DFU_ExecuteApp(1u);

        }

    }

Thanks

Ganesh

0 Likes

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)

0 Likes

Hi,

>>"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:

Store Custom Data in SFlash for PSoC 6 MCU Device – KBA228374

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 !

Thanks

Ganesh