How to save a variable value after power loss on using STM32L5 microcontroller

[ESpra.1]

I'm trying to create a firmware application that can be updated via usb in the field, and most of it is working. I can get the microcontroller to enter and exit bootloader mode by, and I have a program to flash a new firmware update to the microcontroller, then perform a CRC check to confirm the update was successful and uncorrupted.

At the moment, the code works by changing the option bits so that the microcontroller always starts in bootloader mode, then gets forced back into application mode after the new update is flashed and successfully CRC'd

I want to change the option bits back to boot into application mode always until a new update is ready, but I've run into a snag; Right now, I can't get the microcontroller to read the option bits and realize it needs to amend them back to application mode, and I don't want it to be setting the option bits to application mode every time the microcontroller starts application mode.

My current idea is to just use a variable that is saved after power loss to indicate if it has been previously updated or not, but I'm not sure which method of doing that is applicable to my setup.

Also, if anyone has any alternative methods to my own, I'd be happy to hear them

[MM..1]

For example prepare static function , that revert bits to normal and activate watchdog reset.

On update use command go with address to static func.

[Tesla DeLorean]

Perhaps have a boot loader that you never replace that can establish if the main firmware has been updated successfully, or not, and then proceed from there.

You should be able to use sectors/pages in FLASH to store or journal information and there should also be some BKPRAM

[ESpra.1]

I'll look into this option more, but in the meantime I've come across another small wrinkle.

As a temporary measure, I included a case that can be run via a command that arrives via usb to change the option bits back. It works, but the option bits don't take effect until the microcontroller is disconnected and reconnected to power. I also tried running HAL_NVIC_SystemReset to see if that would prompt the desired response, but no luck so far.

I also considered trying to use Programmer CLI commands to cause it to jump to the bootloader's starting address, but I quickly realized that it wouldn't work, since the CLI commands only work for the connections I have if the device is already in bootloader mode, which I would have to power cycle if I wanted it to work.

Is there another command that can cause the microcontroller to reset the microcontroller so that the option bits have an effect right away, rather than having to disconnect and reconnect the power?

[Tesla DeLorean]

You can simply transfer control to another section of code..

[ESpra.1]

Not heard much about that before, but it sounds interesting!

Not sure I understand it from what I've read so far (admittedly little), but are you saying I jump to a specific memory address on the stm32 via application code?

[ESpra.1]

Well, I found the silly mistake of the day. Apparently, if you relock the flash and option bits before you run HAL_FLASH_OB_Launch(), it doesn't work until you power cycle? I'm still parsing out why it works, but removing it from my "set to bootloader mode" and "set to application mode" functions did the trick so far.

If/when I get more answers, I'll update this post for clarity.

[Piranha]

Take a note that modifying option bytes can wear them out and, except for SWAP_BANK option bit, under RDP level 2 option bytes cannot be modified.

For a better and simpler bootloader design look there:

https://community.st.com/s/question/0D50X0000AFpTmUSQV/using-nvicsystemreset-in-bootloaderapplication-jumps