2023-07-28 07:25 AM - edited 2023-09-20 05:18 AM
With STM32L562, I'm implementing a firmware update strategy using the double flash bank.
I write the new firmware in the second bank, then toggle the FLASH_OPTR_SWAP_BANK option bit, and then trigger a reset with OBL_LAUNCH.
To write to the second bank (and to erase it), I need to know which bank is the secondary one (i.e. the one not currently mapped at the lowest address). To do that, I read the FLASH_OPTR_SWAP_BANK bit.
If I toggle this bit, and then a reset occurs (not an OBL_LAUNCH nor a BOR reset; for instance an IWDG reset), will the option bytes be loaded?
The reference manual (RM0438 Rev 7, p.193) states:
Option bytes loading (OBL) is performed in two cases:
– When OBL_LAUNCH bit is set in the Flash non-secure control register (FLASH_NSCR).
– After a power reset (BOR reset or exit from Standby/Shutdown modes).
So, it seems that the option bytes would not be loaded in case of an IWDG reset.
But if they aren't, then I would read a FLASH_OPTR_SWAP_BANK that is not the one actually in use. That is, I would read the one that is set in flash, and not the one that determined the bank memory mapping.
Then, I could start a new firmware update, and in trying to erase the second bank, I would choose the wrong bank, effectively erasing my primary bank, killing the entire application.
How can I prevent this problem?
Should I read the reset cause at every startup (RCC_CSR_OBLRSTF, RCC_CSR_PINRSTF, etc.), and always try an OBL_LAUNCH, so that the option bytes are certainly reloaded, and only continue to the application once I see that the reset is indeed an OBL_LAUNCH reset (RCC_CSR_OBLRSTF) ?
Edit:
From experiments, the option bytes are reverted to their previous value (the latest loaded one, not the latest written one) upon a software reset or an IWDG reset.
Is this behavior reliable?
2023-08-11 04:48 AM
Hello @SZano,
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.