Option bytes all become 0xFF

[Raysu]

The chip model we use is STM32L496VG. Our customer reported that the machine became unresponsive (bricked) and couldn't power on after an OTA upgrade. After receiving the machine, we used STM32 Programmer to read the flash, which prompted chip protection. When we read the option bytes (OB), all contents were found to have become 0xFF. We checked the code but found no section that writes to the OB, and we haven't been able to reproduce the issue. Currently, we want to know under what circumstances the OB would all become 0xFF and what possible causes there might be.

[TDK]

If the option bytes are invalid, or if RDP is 0xFF, the system should be in RDP 1 which means option bytes cannot be read. ST-Link should be giving you an error if that's the case. In which case you're not seeing what the option bytes are, just default values.

> couldn't power on after an OTA upgrade

Your OTA upgrade doesn't touch option bytes? Most likely explanation is that the upgrade failed in some manner. Is RDP set to level 1 during normal operation?

[Pavel A.]

Try "connect under reset" mode; make sure the NRST pin is connected to the st-link.

[Raysu]

Thanks for your reply. We confirm that there is no operation on RDP in the code. In addition to the software perspective, could hardware issues potentially cause the option bytes (OB) to become 0xFF?

[TDK]

Not realistically. Option bytes are stored in flash and require a specific procedure to change them.

On the hardware side, they're in flash memory. It's robust, well tested, and unlikely to change on its own. Not impossible, but unlikely. Usually the answer is more mundane.

Can you read the contents of the flash at 0x08000000? If option bytes are 0xFF, you shouldn't be able to. Shouldn't be able to read option bytes either, which makes me skeptical of their accuracy. No error messages in the STM32CubeProgrammer log?

> we used STM32 Programmer to read the flash, which prompted chip protection

What does "prompted chip protection" mean?

[Raysu]

We can't read the flash at 0x08000000 if option bytes are 0xFF but can read the contents of OB. We also believe that only software can cause the option bytes (OB) to become 0xFF, but currently we are unable to reproduce the issue or locate the problem. Anyway, thank you for your support.

[Pavel A.]

> could hardware issues potentially cause the option bytes (OB) to become 0xFF?

Unless you connect in "under reset" mode, software may be able to disturb the SWD interface (enter low power state, do funny things to the power supply...)

[Raysu]

We have found that when setting BOR_LEV to 6, a reset will cause the Option Bytes (OB) to become 0xFF. According to the manual, the valid values for BOR_LEV are 0, 1, 2, 3, and 4. Therefore, setting an invalid BOR_LEV value in the software will result in all Option Bytes turning to 0xFF. Is my understanding correct?