Jumping from app to own bootloader without reset - good idea? How/when?

[CanisSomnolentus]

Hello,

I have a STM32L0x2 (M0+ core) project where, so far, I used to jump from the MCU app to my custom bootloader for updating the app in flash with a new program binary image, by setting flags in the backup registers and doing a SysReset.

Now, that MCU is controlling something bigger, which actually sends the firmware to it.

While there is a design to be able to hold the power-enable of that bigger SOC when this SysReset (floating MCU pins) happens, there seems to be a design flaw making this somewhat glitchy.

I went this route of resetting because it seemed a no-brainer: everything is clean again.

Would it be feasible, though, to jump to the bootloader, from the app, without doing that, and de-init'ing *almost* everything - except that one GPIO pin that does the power-enable?

I faintly remember some text saying that you *have to* de-configure absolutely everything before doing things like changing VTOR, I can't find it again nor remember why.

But if there was a way to do this and be absolutely sure that the bootloader starts off with a clean system - except the configuration of that one GPIO which needs to remain an output and "HI" for the whole time, that would help with this.

(this was my first custom bootloader, so I'm a bit rusty on the details already again!)

[MM..1]

You can jump, but before need steps similar for jump from bootloader or to system memory etc.

You dont need deconfig everything, but disable all interrupts .

[Uwe Bonnes]

Consider a core reset "SCB_AIRCR = SCB_AIRCR_VECTKEY | SCB_AIRCR_VECTRESET" to start with a core reset.

[CanisSomnolentus]

Thanks! That's a feature I need to keep in the back of my head for other projects.

Seems M0+ core does not have this, I neglected to mention what MCU model I use, now added that to the OP.

[TDK]

Are you talking about jumping to your own custom bootloader? You can configure that any way you want, certainly if you don't mess with that pin's configuration in your bootloader, it will remain constant. The bootloader is just a program, after all.

[CanisSomnolentus]

Yes, custom.

But I just discovered a real mean party pooper to this approach:

The WWDG watchdog.

To quote the RM0367, 25.3.2 Enabling the watchdog:

The watchdog is always disabled after a reset. It is enabled by setting the WDGA bit in the 

WWDG_CR register, then it cannot be disabled again except by a reset.

The whole excercise was to avoid a reset, but the app is using a WWDG.

-

Edit: I guess I could make the re-entered bootloader aware of the necessity to pacify the watchdog. Even though that seems like a bit of a whacky design.

But... what about flashing... is the watchdog sleeping during flashing, or will it screw up things? This MCU has only one flash bank, so during flashing, it's kinda paralyzed.