Application to Bootloader Jump when Watchdog Timesout

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

cross mob
User20222
Level 1
Level 1
First solution authored
Hello! I was wondering if someone could help me understand the jump from application to application in more detail in a two application on one flash target scheme. Currently I am testing on a xmc4700 relax kit.

Application one is the bootloader and lives in flash memory 0x0C000000.
Application two is the application layer and lives in flash memory 0x0C010000
Each application is its own Dave project right now.

I've triggered a manual jump from bootloader to application layer using the abm0 header successfully.

void BL_FlashABM0_Restart(void)
{
/* Restart in alternative bootmode 0 */
/* Clear the reset cause field for proper reset detection of the ssw */
XMC_SCU_RESET_ClearDeviceResetReason();
/* Set ABM0 as boot mode in SWCON field of STCON register */
XMC_SCU_SetBootMode(XMC_SCU_BOOTMODE_ABM0);
/* Trigger power on reset */
PPB->AIRCR = 1 << PPB_AIRCR_SYSRESETREQ_Pos |0x5FA<}


From the application layer, I can also trigger a manual reset to the Bootloader sucessfully

void Reset_to_Bootloader(void)
{
/* Clear the reset cause field for proper reset detection of the ssw */
SCU_RESET->RSTCLR = 1< /* Set ABM0 as boot mode in SWCON field of STCON register */
WR_REG(SCU_GENERAL->STCON,
SCU_GENERAL_STCON_SWCON_Msk,
SCU_GENERAL_STCON_SWCON_Pos,
SW_CONFIG_Normal);
/* request system reset */
PPB->AIRCR = 1 << PPB_AIRCR_SYSRESETREQ_Pos |
0x5FA<}


The scenario is when application layer spins forever in a while loop. The internal watchdog counter times out after a preset time.

Currently, after the bootloader jumps to the application layer, when the watchdog resets in the application layer, I've observed the application gets reset to running again. If possible, can someone help me understand some strategies on how to reset from a watchdog timeout in the application layer and boot back into the bootloader? Is it as simple as simply calling Reset_to_Bootloader() in the Watchdog_Handler(), or should I be messing with some program counter register, reloading the bootloader's vector table, then branching to bootloader?

Thanks!
Brian
0 Likes
4 Replies
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

Yes, you need to change the boot mode back to normal in the watchdog ISR.

BTW: I would use CMSIS NVIC_SystemReset() function instead of
  PPB->AIRCR = 1 << PPB_AIRCR_SYSRESETREQ_Pos |0x5FA<

Regards,
Jesus
0 Likes
User20222
Level 1
Level 1
First solution authored
Hi Jesus,

Thank you for your reply. I've been working on this intermittently, and have a followup question. Since a system reset is generated, all the peripherals get reset, correct? Is it possible to keep the WDT enabled through resets?

A bit of background, if the bootloader jumps from address 0x0C000000 to address 0x0C010000 and there is physically nothing there at the moment, we'd like the WDT to catch that jump and reset back to bootloader. Is this possible with the Infineon provided functions, or should I write a custom jump operation that doesn't actually reset the microcontroller?
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

Would not be easier to check the memory contents (CRC, vector address/stack address) before jumping?

Regards,
Jesus
0 Likes
User20222
Level 1
Level 1
First solution authored
Yes, we will be doing a firmware integrity check (CRC) before jumping. I was thinking of worst case scenario when even if the CRC is valid but the application layer is somewhat corrupted (if even possible), and somehow gets stuck before initializing the watchdog again. Seems like the possibility would be low, but would still like to evaluate all of my options if possible.

Thanks,
Brian
0 Likes