6
\$\begingroup\$

I designed a PCB which has an STM32G431CBT6 on it. There are also two LEDs, a red and a green one, connected as shown:

LEDs

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?


Edit:

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.

By the way, I found the default setting for disabling the pull-down:
(and yes, it is called "pull-up" in the settings, but it seems to be a mistake) pull-down setting

When checked (default), it puts the

HAL_PWREx_DisableUCPDDeadBattery();

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.

Summary:

  1. Originally the LED was dimly lighting up only in reset.
  2. 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.
  3. 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.
\$\endgroup\$
3
  • \$\begingroup\$ I'd like to know what is the absolute voltage on the PB4 when the 120uA flows into it? Is it near 612 mV? \$\endgroup\$
    – Justme
    Aug 19, 2020 at 8:10
  • \$\begingroup\$ No, it's 1.37V, which implies ~11k. It's not the nominal 5.1k that you mentioned in your answer, but I think you are correct, and there may also be a pull-up due to the USB-C. (Although I find it strange that there is a pull-up for the JTRST, and a pull-down for USB-C at the same time.) \$\endgroup\$
    – vjaz
    Aug 19, 2020 at 8:57
  • \$\begingroup\$ Relevant: youtube.com/watch?v=1uEmX5XClPY \$\endgroup\$ Aug 19, 2020 at 18:22

4 Answers 4

11
\$\begingroup\$

It reads in the reference manual that this particular MCU series use PB4 for one of the USB-C connector CC pins. This means that the pin has support for an internal 5.1k pull-down feature turned on by default at reset time, as otherwise it might not be possible to use the bootloader to download firmware over USB-C connector. Thus if JTAG needs to be used then the pull-down can be disabled. So it will affect the LED too.

\$\endgroup\$
0
\$\begingroup\$

What causes the behaviour is some mistake somewhere. Either you are not really connected to the pins you think (even the most veteran engineer can do this), or the manual is in error. You're right. The only way those can be dimly lit is if there's a pull-down.

Sometimes the answer is buried deep in the manual.

If it bugs you , put a strong pull-up on it.

\$\endgroup\$
0
\$\begingroup\$

If it is activated by a default pull-down to GND (and this should be noted in the microprocessor datasheet if this pin has at initialisation a pull-down) then yes its likley to drain some current through the led. Normally the code would initialise any dual-function pins to their correct state, and/or remove any pull-downs/pull-ups that are not required. But in your case you say there's no code. Well with some correctly written initialisation code the LED will be initialised to the correct start-up state (probably OFF by default). If you're loosing sleep over it its best to add a strong pull-up or make sure the code is running as soon as you power-up the board and execute the code.

\$\endgroup\$
-2
\$\begingroup\$

What are the values of the internal pullup/pulldown resistors? I am betting a LOT more than 1K

\$\endgroup\$
3
  • 4
    \$\begingroup\$ Shouldn’t this be a comment? \$\endgroup\$
    – HandyHowie
    Aug 19, 2020 at 8:10
  • \$\begingroup\$ Not if its the answer to why his LED is dim# \$\endgroup\$ Aug 19, 2020 at 8:50
  • 3
    \$\begingroup\$ @DirkBruere Not wishing to be pedantic. I'm meant to make decisions on such things. Agh ! :-) | As worded it's marginal as an answer. You could simply change the wording to make it a statement re probability rather than a question - but eg JustMe has now answered in more detail (about 45 minutes after you). \$\endgroup\$
    – Russell McMahon
    Aug 19, 2020 at 11:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.