Sep 21, 2020
02:19 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 21, 2020
02:19 PM
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.
From the application layer, I can also trigger a manual reset to the Bootloader sucessfully
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
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
4 Replies
Sep 22, 2020
01:58 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 22, 2020
01:58 AM
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
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
Oct 28, 2020
09:33 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 28, 2020
09:33 AM
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?
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?
Oct 30, 2020
07:19 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 30, 2020
07:19 AM
Hi,
Would not be easier to check the memory contents (CRC, vector address/stack address) before jumping?
Regards,
Jesus
Would not be easier to check the memory contents (CRC, vector address/stack address) before jumping?
Regards,
Jesus
Oct 30, 2020
09:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 30, 2020
09:18 AM
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
Thanks,
Brian