Skip to main content
Visitor II
October 18, 2019
Question

Option Bytes programming not working

  • October 18, 2019
  • 3 replies
  • 5107 views

Hello,

I am using v2.2.0 over a ST-Link/V3 (FW version: V3J3M2B3S1).

I connect to a STM32L471RGT6 MCU.

Then I want to change the User Configuration OptionByte IWDG_STOP from 1 to 0.

I get: Error: Option Byte Programming failed.

Is this a bug or am I doing something wrong?

Log:

09:29:04 : Option byte command : -ob IWDG_STOP=0 

09:29:04 : PROGRAMMING OPTION BYTES AREA ...

09:29:04 : Bank : 0x00

09:29:04 : Address : 0x40022020

09:29:04 : Size : 20 Bytes

09:29:04 : Reconnecting...

09:29:05 : Reconnected !

09:29:05 : UPLOADING OPTION BYTES DATA ...

09:29:05 : Bank : 0x00

09:29:05 : Address : 0x40022020

09:29:05 : Size : 20 Bytes

09:29:05 : Bank : 0x01

09:29:05 : Address : 0x40022044

09:29:05 : Size : 16 Bytes

09:29:05 : OPTION BYTE PROGRAMMING VERIFICATION:

09:29:05 : Error: Expected value for Option Byte "IWDG_STOP": 0x0, found: 0x1

09:29:05 : Error: Option Byte Programming failed

    This topic has been closed for replies.

    3 replies

    ST Employee
    October 23, 2019

    Hi @c_dev05​ ,

    Thanks for your feedback.

    This problem will be fixed soon ,in the meantime you can unplug/plug the board after modification of OptionByte  and will be Ok.

    Regards,

    Houda

    c_dev05Author
    Visitor II
    October 23, 2019
    Hello,
    I implemented option modification also into my firmware, that is running on the STM32L4 MCU.
    And I am also seeing strange behavior:
    * I change the option byte; read it back and it still has the same value.
    * I make a reset and it still has the old value
    * I un-power the MCU; wait a few seconds and power again => option byte has new modified value.
    Please can you tell me how you fix this problem in the programmer? I want to do the same in my code.
    regards,
    Explorer II
    February 3, 2021

    I experienced same issue with STM32F427. My board was bricked because of this but I did manage to find a way to revive it again.

    So problem began when I tried to set option bytes from code, something went wrong, and all option bytes were set and none could be removed. I got the same error, doesn't matter if I disconnect/connect/power cycle. Read protect (RDP) is 0xAA.

    3:50:52 : Option byte command : -ob nWRP0=0

     13:50:52 : PROGRAMMING OPTION BYTES AREA ...

     13:50:52 :  Bank         : 0x00

     13:50:52 :  Address      : 0x40023c14

     13:50:52 :  Size         : 8 Bytes

     13:50:52 : UPLOADING OPTION BYTES DATA ...

     13:50:52 :  Bank         : 0x00

     13:50:52 :  Address      : 0x40023c14

     13:50:52 :  Size         : 8 Bytes

     13:50:52 : OPTION BYTE PROGRAMMING VERIFICATION:

     13:50:52 : Error: Expected value for Option Byte "nWRP0": 0x0, found: 0x1

     13:50:52 : Error: Option Byte Programming failed

    Strangely, I tried using the UART bootloader (stm32flash or STM32CubeProgrammer v2.6.0 command line) and it appear to be able to remove write protection and program the MCU, but in reality it does not and problem remains.

    However, adding read protection was possible through STM32CubeProgrammer GUI. I connected by SWD to the MCU and set read protection to level 1. Point of this is that this should cause an MCU internal flash erase operation (does not need debugger) if a read operation is attempted. Now how to trigger that, I found that if I connect by STM32CubeProgrammer GUI in UART mode (see picture below), it gives the option of 'read unprotect (MCU)' which triggers the flash erase operation. This actually fixed my issue and my MCU is alive again.

    UPDATE:

    It is possible to do this without the UART bootloader in command line with these commands:

    STM32_Programmer.sh -c port=swd --optionbytes RDP=0xBB (to enable read out protection)

    STM32_Programmer.sh -c port=swd -rdu (to trigger mass erase)

    The 'read unprotect' option is available also in DFU mode (at least).0693W000007Dm1GQAS.png

    Explorer
    December 16, 2023

    You saved me

    Visitor II
    October 6, 2021

    Thanks for your post, this helped me undo write protections that I had set on my MCU.

    In my case, there was no need to use your "connect under UART" step --> all I needed to do was toggle RDP to level 1, change WRP bits, then toggle RDP back to level 0 to get back to normal.

    Still, WTF?

     0693W00000FBZbdQAH.png