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?