What happens when the CPU enters the default bootloader? STM32L4

[PK.2]

Hi,

what happens when the CPU enters the default bootloader?

AN2606 lists all peripheral units that are always re-initialized (e.g. UART, SPI, I2C, ..)

What happens to the other ports and GPIOs (e.g. Port E/F/G)? Are all GPIOs reset or do they keep their last status?

I want to update from another chip via USART3, but the voltage supply of the chip is at port G. It is necessary that a pin is in a high state. If I jump into the bootloader, the pin is in reset state and the voltage is switched off.

I have already tried to jump into the bootloader with the option bytes and with a direct jump to the memory address. It also works on another board, but the power supply does not depend on a GPIO there either

Is there an application note that describes what the default bootloader does with unused GPIOs? Or do I have no chance and have to write my own boot loader that necessary GPIOs remain in their state?

[Uwe Bonnes]

If you started out the Bootloader from reset,all other GPIO should be in their default state. If you jumped to the bootloader from your user program, other GPIO might keep the state they had in your program.

[Goof Ball]

Hi @Uwe Bonnes​ . You said: "If you jumped to the bootloader from your user program, other GPIO might keep the state they had in your program"

Do you know this for fact? Whether HAL_NVIC_SystemReset() or JumpToBootloader()... all the other GPIO seems to go floating :(

[Goof Ball]

@PK.2​ Did you find a solution? I have the same problem (GPIO port C goes limp when jumping to the bootloader).

[Tesla DeLorean]

It only enables clocks and peripherals it is using, if it uses PC11 I suspect it enables the clocks and blind writes into registers it assumes are at reset defaults.

If you use HAL_NVIC_SystemReset() that's obviously going to reset all the HW registers/settings.

If the system loader doesn't work as you want your options are to use your own loader, or perhaps patch the system loader, or select secondary entry points.

[Goof Ball]

Thanks for the reply @Community member​ ... couple of follow-ons:

1) fyi it is PC15 on an stm32f405 in my particular case, which should be unused for usb, CAN, and the rest of the stuff in AN2606.

2) "patch the system loader". How? This is hard etched in the silicon, no?

3) "select secondary entry points". OOoohh... as in: jump into the bootloader right after the part where it sabotages my GPIO? How?

[waclawek.jan]

You can disassemble or single-step the bootloader to see what does it exactly do.

I personally wouldn't rely on that, though; ST may decide to change the bootloader in the future. In other words, if the behaviour of the default bootloader does not suit your purposes, you ought to write your own.

This said, I do agree that this is a kind of information which should be documented. However, note, that this is a primarily user-driven forum with only casual ST presence; you might want to contact ST directly, through web support form or through FAE.

JW

[Uwe Bonnes]

JumpToBootloader() is different from just jumping to the bootloader. Maybe JumpToBootloader() does the right thing, you have to check.

[Goof Ball]

@Uwe Bonnes​ JumpToBootloader()  does, mostly, just jump to the bootloader. Stepping through the assembly with the debugger: the jump to the bootloader (0x1fff0000 IIRC) occurs with my GPIO untouched. But soon inside the bootloader, the bootloader nukes GPIO. I even tried setting the LCKR (gpio lock) bits, but the bootloader gets around it and nukes GPIO anyway.

Bottom line: I CANNOT find a way to prevent bootloader from messing with GPIO, including GPIO not used by the bootloader.