cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L562 boot into FWU mode for USB via option byte programming

Grizz
Associate III

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

}

}

 

4 REPLIES 4
Grizz
Associate III

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

 

TDK
Super User

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

 

If you feel a post has answered your question, please click "Accept as Solution".
TDK
Super User

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.

If you feel a post has answered your question, please click "Accept as Solution".
Grizz
Associate III

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