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?

[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?

[Pavel A.]

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