I'm working on an application that runs on the STM32F030R8, and I'm prototyping using the ST-Nucleo-F030R8 board with built-in ST-LINK, and IAR Embedded Workbench.
One of the required features of my application is to jump into the System Memory bootloader for firmware updates, and then launch the newly programmed application using the bootloader "Go" command. There are a couple GPIO pins (PB3 and PB9) that need to maintain their output/high state through the duration of the firmware update and subsequent launching of the application.
The "jump into bootloader" portion of the task is working properly. I'm able to jump into the bootloader while retaining the state of the GPIO pins. However, I'm having a problem with the "Go" command. I've set a breakpoint at the application's reset vector, which triggers following execution of the "Go" command. In this breakpoint, I've observed in the debugger register window that the GPIOB registers have all been reset to their default values, and that the clocks to GPIOA and GPIOB (the only GPIO instances I'm using) are disabled in RCC->AHBENR. The registers still contain default values after re-enabling the GPIO clocks.
Judging by AN3155 section 3.5, it appears that it should be possible to retain GPIO state for pins that are not used by the bootloader. One possible issue that's mentioned in AN3155 is this: "it initializes the registers of the peripherals used by the bootloader to their default reset values"
Can someone with knowledge of the STM32 bootloader provide more details about what peripherals are reset to defaults when the "Go" command is invoked? Does this possibly include GPIOA and GPIOB?
If the bootloader isn't expected to modify GPIOA and GPIOB, I'd welcome suggestions on how to debug this issue.
