2025-12-27 1:56 PM
Using the information from the chip's datasheet and reference manual:
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
}
}
2025-12-27 2:12 PM
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?
2025-12-27 4:07 PM
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:
2025-12-27 4:42 PM
You're also missing step 5 in the procedure.
Consider using HAL_FLASHEx_OBProgram which does this for you.
Uploading a program in STM32CubeProgrammer doesn't affect option bytes.
2025-12-27 6:04 PM
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.