2025-08-27 7:43 AM
As the title says, the STM32G47 PA9 pin appears to be set high in boot mode opposed to pulled high though a resistor which is states in AN2606. This is becoming a problem because it introduces negative behaviors in our design when we try to reprogram. Is this a known behavior documented elsewhere?
I have gotten pretty frustrated when migrating from the STMF3 family to the STMG4 since there are many more pins being pulled or set in one direction or another during boot mode.
Is there any way to disable some of these hardware defined communications protocols during the boot loader mode initiated by the BOOT0 pin?
Solved! Go to Solution.
2025-08-27 8:17 AM
> the STM32G47 PA9 pin appears to be set high in boot mode opposed to pulled high though a resistor which is states in AN2606
It's an output pin. It should be in push-pull mode.
I don't see anywhere where it says for STM3247x it's only pulled up. Am I missing it?
> Is there any way to disable some of these hardware defined communications protocols during the boot loader mode initiated by the BOOT0 pin?
Sadly no. The bootloader is in ROM and its behavior cannot be changed.
2025-08-27 8:17 AM
> the STM32G47 PA9 pin appears to be set high in boot mode opposed to pulled high though a resistor which is states in AN2606
It's an output pin. It should be in push-pull mode.
I don't see anywhere where it says for STM3247x it's only pulled up. Am I missing it?
> Is there any way to disable some of these hardware defined communications protocols during the boot loader mode initiated by the BOOT0 pin?
Sadly no. The bootloader is in ROM and its behavior cannot be changed.
2025-08-27 8:24 AM - edited 2025-08-27 8:25 AM
Unless there's an activity at PA10, which the bootloader may judge as start of the UART bootloader, PA9 should not be pulled hard.
While you can't change the bootloader behaviour and there are no sources available, you *can* debug it, including stopping and observing the GPIO and perhaps also the involved peripherals registers' content.
JW
2025-08-27 8:33 AM
I agree that the document says the pin PA9 is in push/pull mode when in the bootloader mode. However, when we tried grounding this pin with a 6k or 1k resistor we are still able to measure 3.3V (Vdd) at the pin which implies the pin is actually driven high opposed to connected high through a pull up.
2025-08-27 9:14 AM - edited 2025-08-27 9:17 AM
> implies the pin is actually driven high opposed to connected high through a pull up.
That's what push/pull mode means. It's driven to VDD (push) or GND (pull) directly, not through a resistor.
2025-08-27 9:30 AM
That is good to know, but I will say that the ambiguity of "Used in alternate push-pull, pull-up mode." is not very clear. If the pin was in pull-up mode or pulled down in push-pull mode I wouldn't have an issue.
2025-08-27 11:10 AM - edited 2025-08-27 11:11 AM
That pin is most probably set only once, at the bootloader start: as AF in GPIOx_MODER (with appropriate AF number in GPIOx_AFRx to map it to UART), and that means, that its directionality (more precisely, its output enable signal) is controlled by the UART. If the UART is disabled or it's transmitter is disabled, that pin is not driven actively. (This is general GPIO behaviour, not bootloader-specific.)
I suspect, that that pin has also its pull-up enabled in GPIOx_PUPDR, to establish a weak one while the UART transmitter is not enabled yet (after entering the bootloader and before detecting UART-bootloader-start at the respective UART_Rx pin); and also that it's set to push-pull in GPIOx_OTYPER (as opposed to open-drain). So that's why that wording, although confusing, it most likely straight comes from the Cube/HAL gobbledygook used to set up that pin.
JW