How to store a 1-bit bootloader flag without wasting 1 Flash page

[bhagat]

Hello,

I am working on custom bootloader + application setup on a STM32G070CBT6

Currently, I need to store bootloader flag that indicate whether the MCU should jump to the bootloader code or to the application code.

• Since the movement i am reserving 1 flash page(2KB) ,just to store single flag bit.
• This feels like a waste of memory, since I only need 1 bit of storage.

My questions are:

     1. Can I use Option Bytes memory area to store the custom flag? 

• Are Option bytes  writable at runtime for application/bootloader use, or are they limited to ST system configurations (e.g., RDP, WRP, BOR levels)?

      2. If Option Bytes memory area are not suitable ,is there another small memory area(apart from flash)

          that is recommended for storing such a small boot flag?

I need only one bit for this flag, but dedicating a full 2KB flash feel inefficient.

[Andrew Neil]

Does this flag need to be non-volatile ?

[mƎALLEm]

Hello @bhagat and welcome to the community,

• Since the movement i am reserving 1 flash page(2KB) ,just to store single flag bit.

Unfortunately, you need to do that when storing that flag in the flash.

Why putting the flag in the flash while you can put it in the RAM?

[bhagat]

Yes, the bootloader flag must be non-volatile, because I need it to persist across a reset.

[AScha.3]

Hi,

>Are Option bytes  writable at runtime

yes ; you could set bootloader/start or not.

+

If you have Vbat/RTC , could use user backup registers, 20 B afair.

[bhagat]

I’m using the flag for my custom bootloader. Since I need the bootloader to check this flag after a reset, it must be stored in a non-volatile location. If I keep it in RAM, the value will be lost once the MCU resets, so the bootloader wouldn’t see it. That’s why I’m not using RAM for this flag.

[MM..1]

Sorry boss, but flags (or any variable) in RAM can persist reset (right config) and not persist power down. Then this is primary condition.

[mƎALLEm]

Try to reserve a location to the RAM not defined in the linker and access to that location by address either from the bootloader or the application. The RAM can preserve its content after reset if it was not modified by a configuration in the linker. For sure it won't preserve its content with power cycle.

Why did you accept my answer as solution while you keep asking? 

[Andrew Neil]

---

@bhagat wrote:

Yes, the bootloader flag must be non-volatile, because I need it to persist across a reset.

---

That's a different thing!

Non-volatile means persisting across power loss/removal.

RAM is volatile (loses content with power loss), but it does persist across a reset.

All you need to do is to ensure that your flag does not get cleared by your startup code.

Check your compiler documentation for how to do that.

For GCC, you use a noinit section ...

https://community.st.com/t5/stm32cubemx-mcus/feature-request-quot-no-init-quot-linker-section/m-p/696858

[Ozone]

> Try to reserve a location to the RAM not defined in the linker and access to that location by address either from the bootloader or the application.

Recommended, but not absolutely necessary. Application and bootloader can share the same range, i.e. the bootloader can try to access variables (addresses) defined within the application.

But this flag area must be excempted from RAM initialisation that happens almost immediately after the reset vector.
And which is implemented in the startup code, usually in assembler.