STM32L462 - Invoking UART bootloader from user program ( without using Boot) pin.

[KK.4]

I working on a STM32L462 project, which needs to invoke the bootloader from the user program. I don't have access to the Boot0 pin. I came across two methods of doing the same but not sure which one should i employ for clean transition.

Method 1: - Set the system memory address in a pointer and set the main stack pointer after which invoke the system memory address.

Method 2: Hardware manual says about writing the option bytes of FLASH_OPTR register to ignore the boot pin ( setting nSWBOOT0 to 0) and setting the nBOOT0(0)and nBOOT1(1) option bytes.

How this two methods are different and which one to employ for a clean transition?

[MM..1]

Method 1 is preffered for start from code, because "is without reset" and if fail turn off on start original fw

but if fail with corrupted app bootloader not repeat start = brick

Method 2 need after options set invoke reset and dfu command run app or/and write options back

[MWB_CHa]

Hi @KK.4​ ,

Previous answer from @MM..1​  fully makes sense of course. Thanks.

I will just add some elements:

• There is a third option: When flash is erased (first sector specifically), HW forces boot to Bootloader whatever the boot configuration (except when nSWBoot0 is set to 0 and nBoot0 set to 1). You may consider this option in your list but it depends on your application requirements/constraints.
• Method 1 has two inconveniences/risks:
  • If the product has dual flash feature (which is the case for STM32L462), you cannot jump to Bootloader from user flash. (it will think it is a dual boot configuration and jump back to user flash). So you have an additional step to do as described in AN2606 page 30.
    • Note: For STM32 devices having the Dual Bank Boot feature, to jump to system memory from user code the user has first to remap the System Memory bootloader at address 0x00000000 using SYSCFG register (except for STM32F7 series), then jump to bootloader. For STM32F7 series, the user has to disable nDBOOT and/or nDBANK features (in option bytes), then jump to bootloader.
  • If you jump to Bootloader while you use some resources that Bootloader need to use, this might corrupt Bootloader operations. (which means you need to cleanup before jump)
• Method 2 is clean and safe if you grant that you have some host communicates with the device bootloader. Otherwise, your application may never start since STM32 will always boot on Bootloader.

All in all, I think it is preferred to use method2 unless there are specific constraints on the application.

And if you use Bootloader only when Flash is erased, then you can use the option I indicated in the beginning, which would be the best option in that case.

I hope it helps.