STM32CubeProgrammer (v2.10.0) is trashing option bytes on the STM32L4R5; leaving the device in an unusable state.

[zfields]

I'm using a Swan R5 (STM32L4R5). About 50% of the time when I flash code using the Arduino IDE, then my option bytes are left in such a state that the device will no longer operate.

I can reset the option bytes and flash the firmware using STM32Programmer application, and the Swan will work as expected.

Here is the bad state set by the Arduino IDE when it errors:

Here is the state I am restoring it to:

I'm running Pop!_OS (Debian) Linux 21.10 and Arduino IDE 1.8.19.

This has happened on two separate boards now. Should I be modifying any additional registers to restore the board, and is there something I can do to prevent this from happening in the future. It did not used to happen before (older version of Linux and Arduino IDE), and now it happens quite frequently.

[fpistm]

Hi @zfields
honestly I don't see any link with this repo. The script simply call the STM32CubeProgrammer cli.

What I suspect is the workaround used to flash properly each time is no longer OK.
(stm32duino/Arduino_Core_STM32#1511)

Which STM32CubeProgrammer version you used ?

Note that I'm always waiting feedback internally on the issue with the flash.

[ABOSTM]

Hi @zfields,
can you also tell us whether you use EEPROM library in you application ?

[zfields]

I do not. This happened while I was working on testing the behavior of while (!Serial);

stm32duino/Arduino_Core_STM32#1672 (comment)

I'm using STM32CubeProgrammer v2.10.0

[fpistm]

Please, could you retry with the previous version you used?
My guess is the workaround (-ob nBOOT0=0 -ob nBOOT0=1) is no more working and could explain why you get this behavior.

[zfields]

You mean to install the previous version of STM32CubeProgrammer? In case it is important, my older STM32CubeProgrammer was v2.9.0.

I did notice that installing software using STM32CubeProgrammer v2.10.0 directly, require me to flash the software twice before it started running on the device.

[fpistm]

You mean to install the previous version of STM32CubeProgrammer? In case it is important, my older STM32CubeProgrammer was v2.9.0.

Yes 😉

I did notice that installing software using STM32CubeProgrammer v2.10.0 directly, require me to flash the software twice before it started running on the device.

That is normal. This is the issue you raised some month ago: stm32duino/Arduino_Core_STM32#1495

So using directly the STM32CubeProgrammer you haven't the workaround which has been proposed in our mail exchange (-ob nBOOT0=0 -ob nBOOT0=1).

[zfields]

I'll install the old STM32CubeProgrammer and test.

[zfields]

It seems to play nice with v2.9.0. 🤷

However, after I switched it to v2.9.0, then it started working fine in v2.10.0 as well.

Do we know what's causing the option bytes to become invalid?

[zfields]

@fpistm I am confused when you say, "That is normal." in regard to have to flash firmware two times. Could you offer an in-depth explanation as to why that is "normal"?

It seems odd to me, but obviously I don't understand it like you do.

[fpistm]

@fpistm I am confused when you say, "That is normal." in regard to have to flash firmware two times. Could you offer an in-depth explanation as to why that is "normal"?

Well, you told that using direclty STM32CubeProgrammer requires to flash twice time the board. I said it is normal as there is an issue with STM32L4+ serie. Remember that this issue was raised by you --> stm32duino/Arduino_Core_STM32#1495 I didn't says it is the normal behavior just you met again the issue as without using Arduino IDE upload method the workaround we deploy is not used.

[fpistm]

Do we know what's causing the option bytes to become invalid?

Unfortunately no. This issue is linked to STM32CubeProgrammer and not to STM32duino stuff.
One possibility is the fact we force nBoot0 OB to be write (the workaround to avoid flash twice).

So are you able to reproduce this issue? If not maybe you got an issue with previous install of the 2.10.0?

[zfields]

No, I have not been able to reproduce the issue - yet. I'll leave my Notes here, in case any one else were to encounter this issue.

Recover STM32L4R5 (Swan)

Occasionally, when flashing firmware with the ST-LINK v3 using the Arduino IDE via SWD, the Option Bytes in the FLASH registers will become invalid.

Example of invalid register values:

FLASH Registers

Register	Value
OPTR	0x08000000
PCROP1SR	0xFFFE0000
PCROP1ER	0xFFFE0000
WRP1AR	0xFF00FF00
WRP2AR	0xFF00FF00
PCROP2SR	0xFFFFFFFF
PCROP2ER	0xFFFF0000
WRP1BR	0xFF00FFFF
WRP2BR	0xFF00FFFF

When the Option Byte registers get into this state, the STM32L4R5 will no longer execute firmware or allow programming. Fortunately, the STM32L4R5 can be recovered using the STM32CubeProgrammer, by updating the following FLASH registers (in the [REG] tab) to the following values:

FLASH Registers

Register	Value
OPTR	0xFFEF98AA
PCROP1SR	0xFFFFFFFF
PCROP1ER	0xFFFF0000
WRP1AR	0xFF00FFFF
WRP2AR	0xFF00FFFF
PCROP2SR	0xFFFFFFFF
PCROP2ER	0xFFFF0000
WRP1BR	0xFF00FFFF
WRP2BR	0xFF00FFFF

After updating the option bytes, the STM32L4R5 can now be programmed using the STM32CubeProgrammer and execute firmware. However, this state is unstable and will likely be short-lived. For unknown reasons, the STM32L4R5 will return to the bad state the next time you try to flash using the Arduino IDE via SWD.

However, if you immediately program the STM32L4R5 using the Arduino IDE via DFU, it appears to update something else ,?other registers, perhaps?, that stabilizes the device settings. Afterward, the device can be debugged and programmed normally via SWD again.

[fpistm]

I was not able to reproduce your issue.
As stated using ArduinoIDE via SWD simply call the STM32CubeProgrammer cli.
So you should be able to reproduce without Arudino using the STM32CubeProgrammer GUI or CLI.
Your note seems not inline with your previous comment about the switch to STM32CubeProgrammer version (2.10.0 --> 2.9.0 --> 2.10.0) :

However, after I switched it to v2.9.0, then it started working fine in v2.10.0 as well.

As it works on your side, I could not reproduce and it is clearly linked to the STM32CubeProgrammer. I close this one.
If you have further issue please contact your FAE which will raised an issue internally to the STM32CubeProgrammer team. Like that you will get feedback directly from expert.