Skip to main content
Explorer II
July 21, 2025
Question

Option bytes config issue

  • July 21, 2025
  • 8 replies
  • 1403 views

Hi,

I am trying lock a portion of Flash memory using WRP(Write Protection). when I am configuring the Option bytes for WRP. I am using STM32L443VC MCU and I have multiple questions:

1. Which area to select WRPAreaA or WRPAreaB for page 0 to page 11 because there is no division of area given?

2. I am trying to lock from page 0 to page 11 in the flash memory but I am seeing different values even after OBL launch:

example: WRPStartOffset = 0x80  (Expected: 0x00)

                WRPEndoffset = 0x0B (Expected: 0x0B)

This is because in the reference manual I see FLASH_WRP1AR reset value is 0xFFXX FFXX and in the register value is 0xFF00 FFFF. If I use Register value got 0xFF0B FF80 instead of 0xFF0B FF00. if I assume 0xFF00 FF00 i am getting 0xFF0BFF00. Even I tried for different page offset still I am seeing Startoffset value different. Please check the attached snapshots for your reference.

3. I am using segger jlink to flash the code and Please let me know how to flash using jlink for option bytes.

Please find the attached documents for your reference.

 

    This topic has been closed for replies.

    8 replies

    Super User
    July 21, 2025

    If you use STM32CubeProgrammer to set the same option bytes, does it work?

    Does the code execute correctly, return HAL_OK, and launch option bytes?

    Rakesh936Author
    Explorer II
    July 22, 2025

    Hi @TDK,

    I tried configuring the option bytes for WRP with STM32CubeProgrammer, It is working and not able to erase the protected areas (STM32CubeProgrammer). I tried mass erase too but it is not erasing as expected(In STM32CubeProgrammer) . Please check the snapshots for the reference. But I am able to erase the memory using JFlash tool. As per Reference manual we cannot erase or program WRP area ??

    In code, It returns HAL_OK and able to Launch Option bytes but the startOffset value is not setting properly (Observed: 0x80 and Expected: 0x00). The FLASH_WRP1AR value is 0xFF00 FFFF before programming. After programming it becomes 0xFF0B FF80 instead of 0xFF0B FF00. Even I am observing same value in STM32CubeProgrammer after flashing the code (Observed: 0x80 and Expected: 0x00).

    How come it is failing in the code? Am I missing any configuration? 

    Super User
    July 22, 2025

    Not real sure. Step through the code and see if WRPEndOffset value ever gets changed. Trace it until it's actually written into the option bytes.

    Rakesh936Author
    Explorer II
    July 23, 2025

    Here is the detailed Observation:

    In FLASH_OB_WRPConfig function, there is a modify_reg operation

    #define MODIFY_REG(REG, CLEARMASK, SETMASK)  WRITE_REG((REG), (((READ_REG(REG)) & (~(CLEARMASK))) | (SETMASK)))
     
    if(WRPArea == OB_WRPAREA_BANK1_AREAA)
    {
          MODIFY_REG(FLASH->WRP1AR, (FLASH_WRP1AR_WRP1A_STRT | FLASH_WRP1AR_WRP1A_END),
                     (WRPStartOffset | (WRDPEndOffset << 16)));
    }
    CLEARMASK = FLASH_WRP1AR_WRP1A_STRT | FLASH_WRP1AR_WRP1A_END = 
    0x0000007F | 0x007F0000 = 0x007F007F.
    SETMASK = (WRPStartOffset | (WRDPEndOffset << 16)) = (0x00 | (0x0B) << 16)) = 0x000B0000
    ~CLEARMASK = ~(0x007F007F) = 0xFF80 FF80
    (READ_REG(REG)) & (~CLEARMASK) = (0xFF00FFFF) & (0xFF80 FF80) = FF00 FF80
    (READ_REG(REG)) & (~CLEARMASK) | (SETMASK) = (FF00 FF80) | (0x000B0000) = 0xFF0B FF80.
    Expected is 0xFF0B FF00, Observed is 0xFF0B FF80.
    READ_REG(REG) value is 0xFF00 FFFF. I saw the same value in registers and in STM32CubeProgrammer.
    In reference manual. reset value is 0xFFXX FFXX.
    The value setting is not as per expected value. Even I can see the values in the STM32CubeProgrammer as observed value(0xFF0B FF80) after flashing the code. 
     
    If I set the offsets in STM32CubeProgrammer, it works but can be erased outside of STM32CubeProgrammer. I am not able to resolve the issue from few weeks now. Can you please help me solve this? Thanks in Advance.
     
    Please find the attached snapshots for the reference.
     
     
     
    Super User
    July 23, 2025

    Ignoring the 0x80 vs 0x00 mismatch, is the behavior as expected? After running the code to set the pages to write protected, are the flash pages 0-11 write protected and how are you verifying that?

     

     

    ----

     

     

    In the Reference Manual, these fields are 8 bits in width

    TDK_0-1753274822756.png

     

    In the CMSIS files, these fields are only 7 bits in width.

    TDK_1-1753274862588.png

    cmsis-device-l4/Include/stm32l443xx.h at a2530753e86dd326a75467d28feb92e2ba7d0df2 · STMicroelectronics/cmsis-device-l4

     

    Because the default value for WRP1A_START is 0xFF, when the program tries to change it to 0x00, it doesn't modify the 8th bit, so it gets set to 0x80 instead.

     

    The CMSIS file for various STM32L4 chips seem to set the width of this field based on how much flash memory is available, but that doesn't seem to be correct per the RM.

    Rakesh936Author
    Explorer II
    July 23, 2025

    After flashing the code and resetting the MCU, the lock was not enabled as I can mass erase the flash memory.

    To verify the configuration I have connected to STM32CubeProgrammer in which I saw startoffset as 0x80 and endoffset as 0x0B. Even I tried for different pageoffset I see always the startoffset is not correct where as endoffset is correct. When the flash memory is erased I see the default value (0xFF00 FFFF).

    You mentioned there is a difference in width of bits, Is there any way to make the startoffset to work as expected?

     

    Super User
    July 23, 2025

    I will request someone take a look.

    You could modify the registers directly instead of relying on HAL. Otherwise, you will wait to see if it is fixed which will take a while.

    Technical Moderator
    July 24, 2025

    Dear @Rakesh936  @TDK ,

    Thank you for highlighting such behavior to us, as well pointed by @TDK can you update manually at your local file that CMSIS file by:

    /****************** Bits definition for FLASH_WRP1AR register ***************/
    #define FLASH_WRP1AR_WRP1A_STRT_Pos (0U)
    #define FLASH_WRP1AR_WRP1A_STRT_Msk (0xFFUL << FLASH_WRP1AR_WRP1A_STRT_Pos) /*!< 0x000000FF */
    #define FLASH_WRP1AR_WRP1A_STRT FLASH_WRP1AR_WRP1A_STRT_Msk
    #define FLASH_WRP1AR_WRP1A_END_Pos (16U)
    #define FLASH_WRP1AR_WRP1A_END_Msk (0xFFUL << FLASH_WRP1AR_WRP1A_END_Pos) /*!< 0x00FF0000 */#define FLASH_WRP1AR_WRP1A_END FLASH_WRP1AR_WRP1A_END_Msk

    and let us know if the behavior is fixed ?  

    In our Reference Manual we are using the 8-bits for decoding logic, and I believe it is correct on How the start and end pages works.     Here is an internal Ticket Number for Follow-up in future #214744

    Thank you.

    STOne-32.

    Rakesh936Author
    Explorer II
    July 25, 2025

    Hi @STOne-32,

    @TDK  Thanks for the follow up.

    I have updated the change in local file and the issue is fixed. WRP is enabled and verified in STM32CubeProgrammer. 

    Observation from STM32CubeProgrammer:

    WRP enabled and offset are properly set.

    Unable to erase the protected areas, but able to erase unprotected areas(expected).

    Mass erase is failing as expected.

    But I was able to mass erase the flash memory using Jflash tool(Debugger: Segger Jlink). I am not sure why this is happening?

    As per RM, Once WRP is enabled we cannot erase or program the WRP area and mass erase is not possible.

    Can you please let me know the reason behind this behaviour? Thanks in advance.

     

     

    Technical Moderator
    July 25, 2025

    Dear @Rakesh936 ,

    Thanks for the follow-up . regarding Jflash tool from Segger , I believe the key word in our manual is “software” mass erase, it  is not possible if one page is Write protected . That means the embedded firmware  executed from Flash or RAM by CPU can not erase it self or do a mass erase. However with Jflash or Programmer they take the control over JTAG/SWD to the flash and have the ability to have back the device to a virgin ( out of factory) with A mass erase .   In that case, we need to go to further level of protection and disabling the Debug I/F once your end product is released to market .

    Hope it helps you,

    STOne-32

    Rakesh936Author
    Explorer II
    July 25, 2025

    Hi @STOne-32,

    Thanks for the reply.

    I understood the issue.

    Thank you 

    @Rakesh936