STM32G030 BOOT0 versus SWD

[FrankNatoli]

STM32G030 datasheet indicates BOOT0 is PA14-BOOT0 and that SWDIO is PA13 and SWDCLK is PA14-BOOT0.
Upon power up, how does the STM32G030 know whether PA14-BOOT0 is controlling whether to enter bootloader mode or is SWDCLK?
Since STM32G030 has no JTAG capability, SWD appears to be the only alternative, and if SWD is connected on PA13 and PA14-BOOT0 does that mean PA14-BOOT0 cannot be used for bootloader purposes?

[Issamos]

Hello @FrankNatoli

As indicated in the datasheet of the STM32G030. Upon reset, PA13 and PA14 are configured as SW debug alternate functions, and the internal pull-up on PA13 pin and the internal pull-down on PA14 pin are activated.

Else, after power-up or reset you can configure them to AF0 to be used for SWD. And will keep useful for bootloader since the activation of bootloader doesn't depend only on the Boot0 state but it needs a full sequence (Boot0(pin) = 1, nBoot1(bit) = 1 and nBOOT0_SEL (bit) = 0) to be activated do the necessary configuration on the FLASH option register (FLASH_OPTR).

Best regards.

II

[FrankNatoli]

I realize that AN2606 4.1 Bootloader Activation Table 2 defines various bootloader activation patterns, and what you describe above appears to be one of the Pattern 11 sequences but I cannot find documentation describing how to control nBoot1(bit) and/or nBOOT0_SEL(bit). They're apparently not STM32G030 pins. How does one control those bits at reset time?

[Aime]

Hi @FrankNatoli ,

As you mentioned PA14-BOOT0 pin is also used as SWDCLK for debug purpose. The default configuration is for the SWDCLK.
It is also indicated in the reference manual RM0444 rev 5: section 2.5 Section Boot configuration that the boot mode configuration is latched on the 4th rising edge of SYSCLK after a reset or a power up. It is up to the user to set boot mode configuration related to the required boot mode. The boot mode configuration is also re-sampled when exiting from Standby mode.

The option bytes nBOOT1, BOOT_SEL and nBOOT0 allow the user to between two different boot modes

These bits can be changed through STM32CubeProgrammer in the option bytes section. 

Best regards,
Aime

[FrankNatoli]

I presently have a EE wiring up an SWD connection to the STM32G030.
With that, I presume I will be able to use STMCubeProgrammer to both burn user firmware and diddle MCU option bits.
However, it is still not clear to me how PA14_BOOT0 manages to serve both SWDCLK and BOOT0.
If, with STMCubeProgrammer, I assert the nBOOT0 and nBOOT_SEL bits, and externally programmatically assert BOOT0 pin, can I then via I2C write user firmware flash memory?
But is SWD then still usable?
If SWD is then still usable, how does the MCU know to use PA14 as BOOT0 not SWDCLK or vice versa?
Seems like a one-or-the-other situation, not both.

[Aime]

Hi @FrankNatoli ,

The option bytes nBOOT1, BOOT_SEL and nBOOT0 allow the user to between two different boot modes, and two use cases for PA14.

• First case: the user changes the option bytes and does not use the PA14 pin as BOOT0. In that case the Boot configuration will be based on the option byte nBOOT0. PA14 can be used as SWCLK for debug purpose. 
  
  
• Second case: PA14 pin is used for BOOT0. As indicated in the reference manual, the Boot level will be sampled on the 4th rising edge of SYSCLK after a reset or a power up. Once sampled, PA14 can be used as SWD for debug purpose.

Caution: BOOT0 pin shares the same GPIO with serial wire clock (SWCLK) that is used by the debugger to connect with the device, based on the fact that these functionalities can be considered almost completely disjoint. Nevertheless, to ensure system robustness, the STM32G0x1 devices provide an hardware mechanism to force BOOT0 low (boot from User flash memory) if a debugger access is detected (and BOOT0 information is taken from the pin), in order to use SWCLK clock for debugger serial communications and at the same time have a safe boot configuration for the device itself. This configuration is kept until next power-on following debugger access.

Best regards,
Aime

[FrankNatoli]

Aime:
Many thanks for your information.
However, please clarify, what combination of PA14_BOOT0 pin and option bits BOOT_LOCK, nBOOT1, nBOOT_SEL and nBOOT0 starts the STM32G030 MCU bootloader, that then allows I2C to burn user flash memory?
And with that specific combination of PA14_BOOT0 pin and option bits BOOT_LOCK, nBOOT1, nBOOT_SEL and nBOOT0, can SWD still function?
All I want to accomplish is have an external host use I2C to burn STM32G030 user flash, then restart STM32G030 using user flash.
Default values of BOOT_LOCK, nBOOT1, nBOOT_SEL and nBOOT0 appear to block that functionality.
My EE does not know whether allowing me to assert or negate PA14_BOOT0 may short or break SWCLK.

[Aime · Accepted solution]

Hi @FrankNatoli ,

I shared with you all the combinations to select the boot area. Let me share again the table.

To start the MCU from the bootloader or "System memory" you have to use one of these configurations. Once in the bootloader, you will be able to use I2C to program the main flash memory. Once programed to start form the flash you have to change again the option bytes.

Another particularity on G0, there is the empty check implemented to allow easy programming of virgin devices by the bootloader. Here is the reference manual description :
Internal empty check flag (the EMPTY bit of the FLASH access control register (FLASH_ACR)) is implemented to allow easy programming of virgin devices by the bootloader. This flag is used when BOOT0 pin is defining Main Flash memory as the target boot area. When the flag is set, the device is considered as empty and System memory (bootloader) is selected instead of the Main Flash as a boot area to allow user to program the Flash memory.

BR
Aime