How to modify Option Bytes on STM32l47 MCU

[TJime.1]

MCU: STM32l47xxx

Hi,

I am attempting to modify Option Bytes in code and am seeing undesirable behavior.

The purpose for modifying the OBs is to be able to reset into Bank 2 afterward. I am implementing to perform a on-the-fly DFU similar to the method found in AN4767. I have looked at both AN 4657 and its example code and followed their method in order to modify the OBs.

After running the code below, the MCU halts and becomes unresponsive. The only way to get it out of this state is to reset the OBs using JLinkSTM32.

I have also looked at the datasheet for this MCU and followed their steps, I am not using HAL libraries so everything is through registers.

Is there a missing step that I am not understanding that is preventing the MCU to reset into Bank 2? I have flashed my application at the start of Bank 2 to test if its working.

Any help would be appreciated!

-Tom

// Function to program the options bytes
void ProgramOptionsBytes(void)
{
  SYS_UnlockFlashWrite();
 
  while (FLASH->SR & FLASH_SR_BSY);
 
  FLASH->SR |= FLASH_SR_OPTVERR; // Clear any previous errors
  // Enable the Flash option bytes access
  FLASH->OPTKEYR = FLASH_OPTKEY1;
  FLASH->OPTKEYR = FLASH_OPTKEY2;
 
  while (FLASH->SR & FLASH_SR_BSY);
 
  // Enable the use of the 2nd bank of memory for code execution
  FLASH->OPTR = 0xFFFFF8AA;
 
  // Program the new options bytes configuration
  FLASH->CR |= FLASH_CR_OPTSTRT;
 
  // Wait for the programming to complete
  while (FLASH->SR & FLASH_SR_BSY);
 
  FLASH->CR |= FLASH_CR_OBL_LAUNCH;
}

[FBL]

Hello @TJime.1​ 

Could you try to clear the FLASH_SR_OPTVERR FLASH Option validity error flag before unlocking the Options Bytes?

You may get inspired with the example provided.

STM32CubeL4/Projects/STM32L476G-EVAL/Examples/FLASH/FLASH_DualBoot at master · STMicroelectronics/STM32CubeL4 (github.com)

[waclawek.jan · Accepted solution]

> After running the code below, the MCU halts and becomes unresponsive.

What do you mean exactly by this? How did you test this? Did you try to debug?

Can't this be the same problem as here, i.e. with BFB2, system memory is mapped at 0x0000'0000 and VTOR pointing to the same address?

JW

[TJime.1]

Hi,

First off, thank you both for responding.

@Community member​  This solved my issue, I was missing a call to re-map VTOR if code was being executed from Bank 2.

I can see that the new FW in Bank 2 is running correctly.. The issue now is that the new FW only executes after a power cycle instead of the desired reset after calling FLASH->CR |= FLASH_CR_OBL_LAUNCH;

Any tips regarding this issue?

Thanks again,

-Tom

[Piranha]

Read this topic:

https://community.st.com/s/question/0D53W00002AT9iZSAT/how-to-regress-stm32u585based-device-from-rdp-2-to-0-without-completely-removing-power-from-the-device

[waclawek.jan]

> The issue now is that the new FW only executes after a power cycle instead of the desired reset after calling FLASH->CR |= FLASH_CR_OBL_LAUNCH;

Does it generate a reset at all, i.e. does boot from bank 1? Or what exactly are the symptoms?

Doesn't it need unlocking OPTLOCK again? What's your NSS pin arrangement?

JW