How to Reliably Disable BOR_EN in Production for STM32G0B1RET6

[Anagha_Sasindran]

Hello,

We are currently facing an issue related to the BOR_EN (Brown-Out Reset Enable) option byte during production on the STM32G0B1RET6 .

In our firmware, we do not modify the option byte registers. On some boards, we observed that the BOR_EN bit is enabled by default. When this is the case and the supply voltage is below the BOR threshold (e.g., 2.2V), the MCU enters a continuous reset loop and the application never starts.

This raises a few important questions:

1. What is the recommended approach to ensure BOR_EN is disabled during production flashing?

2. Should this configuration be explicitly included in the production flashing script?

3. Is disabling BOR_EN from firmware a viable solution?

   • Our understanding is that the value of this bit is applied very early during the boot process—before the application code begins execution. If the application cannot start due to a BOR-induced reset, then any firmware attempt to modify the option bytes would never take effect.

4. Is there any configuration mechanism available (e.g., via CubeProgrammer or similar tools) to reliably ensure BOR_EN is disabled before flashing the firmware?

We are looking for a robust and consistent method to ensure that all production units behave as expected at startup, particularly in cases where supply voltage may momentarily dip below the BOR threshold.

Any guidance on this would be greatly appreciated.

[TDK]

> What is the recommended approach to ensure BOR_EN is disabled during production flashing?

Ultimately up to you, but:

> Should this configuration be explicitly included in the production flashing script?

If it were my project, absolutely yes. Use STM32CubeProgrammer_CLI. It's easy to do so.

> Is disabling BOR_EN from firmware a viable solution?

Yes, you can check for it upon program start and change the bit and reapply option bytes if needed. More complicated than the previous option and prone to error. Naturally, if voltage is insufficient for the current BOR level, this will not work.

> Is there any configuration mechanism available (e.g., via CubeProgrammer or similar tools) to reliably ensure BOR_EN is disabled before flashing the firmware?

You can check it and disable it in STM32CubeProgrammer, in either the GUI or (recommended) the CLI with a single command, either at the same time as flashing or in a separate command.

[Andrei Chichak]

In your initialization code, check the option bits and bytes for the state of the BOR_EN bit. If it's wrong, enable flash writes, turn off BOR_EN, execute the flash update.

The next time your system boots, it does the same thing, but the check of BOR_EN will show that it is disabled and you bypass the flash writes. This takes just a few cycles at boot time and you don't have to worry about your CM doing it wrong.

[Anagha_Sasindran]

Thank you for the explanation.

If BOR_EN is already enabled in the option bytes and the supply voltage at power-on is below the BOR threshold (e.g., 2.2V), wouldn't the MCU enter a continuous reset loop before the application code is able to execute?

n such a scenario, since the application never reaches the point where it can check and update the option bytes, is it still viable to rely on firmware-based modification of the BOR_EN bit? Wouldn’t the only reliable solution be to ensure that BOR_EN is cleared before flashing, as part of the production programming script?

Would appreciate any clarification on this point.

[LCE]

I wonder where you're actually going with this... 

Do you supply the MCU directly with a battery or supercap?

Without internal BOR and without external reset controller, terrible things can happen at voltage "dips" below the lowest working voltage of an MCU, so I'd say you absolutely need either or both.

[TDK]

> If BOR_EN is already enabled in the option bytes and the supply voltage at power-on is below the BOR threshold (e.g., 2.2V), wouldn't the MCU enter a continuous reset loop before the application code is able to execute?

As I said up above, yes this will happen and yes this is a potential issue. Hence the recommendation to change it during the initial programming procedure.

[Andrei Chichak]

Before this goes way way way down a rabbit hole, if you look at page 83 of RM0444, you will see that the factory reset value of BOR_EN is 0/disabled/nada/off. So the values of BORF and BORR are not used and the default BOR level of 1.6V(???) is used.

Either way, the processor is HELD in reset until the incoming voltage hits the BOR level, there is no reset loop.

But, if you put code to clear BOR_EN? Give the processor enough voltage to boot once and the FLASH values will get set the way you want. After that, it's done. But either way, BOR_EN is cleared at the chip manufacturing stage and the processor will boot at 1.6V. 

[Anagha_Sasindran]

Thank you all for your valuable inputs and the clarification on how BOR_EN works.

Apologies if my initial query caused any confusion. Let me explain the context and issue more clearly.

In our production setup, the team observed that some MCUs failed to boot when powered at voltages between 1.7V and 2.2V. According to the datasheet, the minimum supply voltage is 1.7V, so this range should be acceptable for normal operation. However, these MCUs were found to be held in reset, and the application never started.

Upon further investigation, the team discovered that the BOR_EN bit was enabled on the affected MCUs. After disabling BOR_EN using STM32CubeProgrammer, those same units began working as expected at the same supply voltage. Additionally, increasing the voltage beyond 2.2V also allowed the devices to boot, which aligns with the BOR threshold level.

Although documentation indicates that BOR_EN should be disabled by default, testing showed that on some devices it appears to be enabled.To simplify the production process and avoid manual intervention, the team has been exploring the best way to ensure BOR_EN remains consistently disabled.

Based on our current understanding, since the application firmware cannot run unless the device has successfully booted, any attempt to clear BOR_EN at runtime would only work if the voltage is already above the BOR threshold. This may not be the case in all production setups. With that in mind, the team has been exploring ways to ensure the correct configuration is applied earlier in the process—potentially as part of the production flashing script—to achieve consistent behavior across all units. We'd appreciate any thoughts on whether this approach aligns well with best practices.

[TDK]

Might want to figure out how BOR_EN got set. Sounds like option bytes are already getting programmed in your current operation.

[LCE]

At least from within source code, writing option bytes is not that simple - which is good.

I remember faintly that there was something with reset / relaunch until newly written option bytes come into effect, maybe there's something going wrong while flashing? -> check RM