stm32l432 boot sequence (specifically from previously empty flash)

[Geoffrey1]

Posted on March 27, 2018 at 15:36

The stm32l432 reference manual has the following cryptic remark about the boot sequence

'A Flash empty check mechanism is implemented to force the boot from system Flash if the first Flash memory location is not programmed (0xFFFF FFFF) and if the boot selection was configured to boot from the main Flash.'

But does not specify when this check occurs.  I've found the following anomaly that may relate to this.  

1) Start with an erased device

2) Program the part

3) Without power cycling, reset

In this case, the part will jump to the system boot loader.  However, the mysterious thing is that  SYSCFG->MEMRMP is 0 (indicating that the memory is not remapped).   I don't see how it is possible to boot to the programmed code without a power cycle -- even through the SWD interface, because it appears that the 'Flash empty check' is persistent.   What am I missing ?    I know how to use the SWD interface to access all of the stm32 resources, but I don't see what visible state is affecting the boot sequence.

[MSonn]

Hi Nickname6476,

We seem to have the same issue with STM32L496.

We program a new device (which has its flash empty). Then, in order for it to boot from flash we must power-cycle it (or otherwise it seems to keep booting into bootloader)

Do you happen to have some more info please?

Thanks,

Moti

[Geoffrey1]

I don't have any further information. Actually, this worries me a bit since I'm building very small devices with soldered on batteries. While I have a process that can handle the initial case -- program the parts before adding the battery -- I'm concerned about what happens if I reprogram the parts and get into this state.

[Tesla DeLorean]

Ok, if NVIC_SystemReset() isn't sufficient, what about a transition through STANDBY?

[Geoffrey1]

Ok, it's super irritating that nobody from ST has weighed in on what is clearly an issue with the STM32L4. I appreciate Clive's suggestion, but really don't want to try random things requiring a lot of work. I want a clear explanation of what the bootloader hardware support is doing, why, and how to flash and reset a battery powered device when disconnecting power is infeasible.

[Geoffrey1]

ok, I haven't tried this yet. The following note in the reference manual about the flash status register FLASH_SR:

Set by hardware on power-on reset or after OBL_LAUNCH command execution

if the Flash is not programmed and the user intends to boot from the main Flash.

Cleared by hardware on power-on reset or after OBL_LAUNCH command

execution if the Flash is programmed and the user intends to boot from main

Flash. This bit can also be set and cleared by software.

1: The bit value is toggling

0: No effect

This bit can be set to clear the Program Empty bit if an OBL_LAUNCH is done by

software after Flash programming (boot in main flash selected). It finally forces

the boot in the main flash, without loosing the debugger connection.

So it looks like (still need to test) that after a flashing a blank memory, it's necessary to either do a power cycle or set the OBL_LAUNCH bit in the FLASH_CR

[Tesla DeLorean]

It is Europe, I assume everyone disappears through August.. Poke your local FAE

Not sure it was random, bit of a cheap shot perhaps, but based on some sound reasoning/logic, and the assumption you're were not using a plutonium battery, and the device would being going into STANDBY in the nature order of things to have some discernible battery life.

[Geoffrey1]

Perhaps a cheap shot -- my apologies. But, getting to shutdown from the debugger interface is a bit harder than from code since it requires injecting some code and then executing it. I did try out OBL_LAUNCH above without success (even after unlocking the flash). I'm looking for a solution that can easily be performed through the debugger.

[Geoffrey1]

I didn't like going through gdb. Here's an openocd routine that will do the job :

proc clear_erase () {

  reset halt

  puts [reg 15]

  step

  mdw 0x40022014 1

  # unlock flash                                

  mww 0x40022008 0x45670123

  mww 0x40022008 0xCDEF89AB

  mdw 0x40022014 1

  # unlock option                               

  mww 0x4002200c 0x08192A3B

  mww 0x4002200c 0x4C5D6E7F

  mdw 0x40022014 1

  # lauch option byte loader                          

  puts "launch option byte loader"

  mww 0x40022014 0x08000000

}

Here's a gdb script that seems to do the trick -- it connects to the serve (openocd), loads the binary and steps into the reset vector, unlocks the flash, write the flash CR, steps, and exits. Along the way it prints the contents of the flash CR serveral times.

target ext :3333

load

step

p/x *0x40022014

set *0x40022008=0x45670123 

set *0x40022008=0xCDEF89AB

p/x *0x40022014

set *0x40022014=0x08000000

step

p/x *0x40022014

c