Skip to main content
Explorer
December 27, 2025
Question

STM32L562 boot into FWU mode for USB via option byte programming

  • December 27, 2025
  • 3 replies
  • 49 views

Using the information from the chip's datasheet and reference manual:

Grizz_0-1766872306430.png

I have the following routine (using the HAL routines).  My issue is that I have verified code execution and setting of the two OB values via JTAG, but when the system reset is issued I go right back into user code at 0x0800 0000 and not the DFU loader as expected (0x0BF9 0000).

This seems like it should be simple... what am I missing or doing wrong?  

 

void EnterFirmwareUpdateMode(void)

{

HAL_StatusTypeDef status;

 

// See RM0438 STM32L562 Ref Manual - pg 193 sect 6.4.2 option bytes programming

// See boot configuration pg 98 table 6, line 4 - Set Flash OPTR nBoot0 to 0 and nSWBOOT0 to 0

status = HAL_FLASH_Unlock();

status = HAL_FLASH_OB_Unlock();

 

CLEAR_BIT(FLASH->OPTR, FLASH_OPTR_nSWBOOT0_Msk);

CLEAR_BIT(FLASH->OPTR, FLASH_OPTR_nBOOT0_Msk);

SET_BIT(FLASH->NSCR, FLASH_NSCR_OPTSTRT_Msk);

 

// Seems un-needed since Launch supposedly reboots processor

status = HAL_FLASH_OB_Lock();

status = HAL_FLASH_Lock();

 

// Reload option bytes before rebooting

HAL_FLASH_OB_Launch();

 

// Perform System Reset

NVIC_SystemReset();

 

// Question to self -- do I need to reverse the option bytes in my main entry code if loader ran?

 

while(1)

{

; // execution should not get here

}

}

 

    This topic has been closed for replies.

    3 replies

    GrizzAuthor
    Explorer
    December 27, 2025

    I tried changing the sequence up slightly... as you can see, via JTAG, we can verify the two option bits do get set to 0, however, HAL_FLASH_OB_Launch seems to reset them both to 1.  And this explains why we go to user code and not DFU.  What do I need to do to get these options to persist for the restart into DFU?

    Second question:  Once I update firmware via the ST programmer, do I need to toggle the option bits back to 1:1 for normal user mode or does the  DFU tool do this for you automatically?

     

    Grizz_0-1766873309742.png

     

    Super User
    December 28, 2025

    You need to launch option bytes while they are still unlocked.

    Here's a random example that shows how to use HAL_FLASH_OB_Launch correctly:

    STM32CubeL5/Projects/STM32L562E-DK/Examples/FLASH/FLASH_WriteProtection/Src/main.c at 0ae29ef5d6cab23f1d0c15aa948bf0b36285c6d9 · STMicroelectronics/STM32CubeL5

     

    Super User
    December 28, 2025

    You're also missing step 5 in the procedure.

    TDK_0-1766882384132.png

    Consider using HAL_FLASHEx_OBProgram which does this for you.

     

    Uploading a program in STM32CubeProgrammer doesn't affect option bytes.

    GrizzAuthor
    Explorer
    December 28, 2025

    I looked through the sample you pointed to and reviewed your sequence above.  I modified the code as follows and now the status returned from Wait for last op is 128 -- FLASH_NSSR_NSPGSERR  -- programming sequence error.

    What am I missing?  Flash and option bytes are unlocked, clearing the 2 boot bits shows 0s.  Opstart followed by wait for bsy to clear returns error 128.  Isn't this the sequence needed? 

    I looked at  HAL_FLASHEx_OBProgram  but that code looks like a sludgehammer to hit a small tack.

    Grizz_0-1766887240243.png