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.