Gpio status during bootmode

[abhijith_raj]

Hi, 

I am working in STM32G491, currently working on MCU firmware upgrade part. I have a doubt regarding the output pins. Currently we have SET 2 GPIOs to high. That is power enable for another device say A. From another external device B, it is controlling bootpin and nrst pin. 

My doubt is if I make mcu to bootmode does that GPIO output value changes?

The situatuion is during device running, I make 2 gpio high. From another device mcu got entered to bootmode. Does the output pin change the high value?

[waclawek.jan]

By "bootmode", you mean the default bootloder  in System ROM? And you enter it through reset?

If yes, reset itself sets all pins to their defaults as given by reset values of the GPIO registers; and the bootloader sets those pins which it uses, see AN2606, usually to pulled-up input state, unless given interface gets activated. This is unfortunately poorly documented.

In some STM32 the dead-battery USB-C mechamism also causes surprising pin states.

JW

[FBL]

Hi @abhijith_raj @waclawek.jan 

It is already mentioned in footnote 5 of table Table 12. STM32G491xC/xE pin definition in datasheet.  After reset, a pull-down resistor is present because of the electrical characteristics of DBCC pins.

Also caution is mentioned in FAQ: Using dead battery pins in an STM32 with an i... - STMicroelectronics Community

User should be aware of differences in output timing, speed, and leakage for FT_c FT_d GPIOs compared to standard GPIOs.

[waclawek.jan]

Hi @FBL ,

Thanks for the comment.

> User should be aware of differences in output timing, speed, and leakage for FT_c FT_d GPIOs compared to standard GPIOs.

Indeed, the FT_c are just as limited drive as the backup-domain pins, although for different reasons and with different particularitiies. Something to be borne in mind, though.

The FT_d pulldown, presented as a 9uA leakage, interesting, too.

These all are valid points; however, what I had in mind more than anything else is that the 5k1 pulldown on CC pins are controlled by level at the DBCC pin, and that creates surprising effects if one is not aware of this. In particular, e.g. in 'G4, PA9/PA10 are UART bootloader pins AND DBCC pins too, "controlling" PB4/PB6 CC pins, so if there's something critical at those pins (e.g. power control), that might result in nasty surprises, unless the bootloader switches this off.

So the question here is, does the bootloader switch off UCPD DB or not, in the various UCPD-enabled STM32, and how is that documented e.g. in AN2606?

JW

 

[FBL]

Hi @waclawek.jan 

After reset, the pull-down effect on the CC lines can be removed by using the bit UCPD1_DBDIS =1 (USB Type-C and power delivery dead battery disable) in the PWR_CR3 register.

However, during reset, the ultimate solution would be to pull down the pin by HW.

I assume this is not managed by internal bootloader firmware. Let me check and get back to you ASAP!

[FBL]

Hi @waclawek.jan 

I got the confirmation STM32G4 bootloader does not modify UCPD. To conclude, to enter bootloader, we have 2 methods :

• Either after reset, STM32 as in it's reset state, this pull down effect, it must be already disabled.
• Or, after jump from application: in this case, the application must ensure to disable it

[waclawek.jan]

Hi @FBL ,

thanks for confirming this.

JW