I designed a PCB which has an STM32G431CBT6 on it. There are also two LEDs, a red and a green one, connected as shown:
When I powered it on the first time (so no program on the uC yet), the red LED was lighting dimly. After loading a LED blinker program on the uC, it works fine (with full brigthness), however if I press the reset button, the red LED is lighting dimly again and the voltage across R1 is 120mV. So 120uA is flowing for some reason. The other LED doesn't do this, and the voltage across R2 is 0.
Looking at the datasheet I only found this note about PB4 (page 60):
"After reset, these pins are configured as JTAG/SW debug alternate functions, and the internal pull-up on PA15, PA13, PB4 pins and the internal pull-down on PA14 pin are activated."
But even if there is a pull-up on PB4, the LED shouldn't be on, so what causes this behaviour?
After setting the project aside for a while, it doesn't do that now, but I don't know what has changed. I was only tinkering with the boot settings in the option bytes (with the ST-Link Utility), although I don't think that has anything to do with the UCPD pull-down.
When checked (default), it puts the
function call into the HAL_MspInit function.
When unchecked, the LED was lighting dimly even after reset, so it verified the accepted answer to the original question. Until it started to never do the dim lighting again.
- Originally the LED was dimly lighting up only in reset.
- This was because of the UCPD pull-down, which was disabled by the "save power of non-active UCPD - deactive Dead Battery pull-up" checkbox being checked by default. I could verify this by unchecking it and not configuring the GPIO pin for the LED, which resulted in dim lighting even after reset.
- Something happened and now it never does that, regardless of the checkbox or being in reset. Maybe the pull-down has broken for some reason? I only know that the GPIO pin itself is functional, it can drive the LED properly when programmed.