Strange behaviour with STM32G474QE pin PB4

[SStor]

I use pin PB4 on STM32G474QE as normal GPIO output. The external load is ~20kOhm to GND.

There is a strange behaviour after reset without any further initialization:

1. It seems to be an internal pullup <10kOhm that drives the output to high

2. Another pulldown circuit controlled by PA10 seems to drive the PB4 to low.

The pulldown behaviour from 2nd is described in manual as "dead battery support" and should be explainable:

"After reset, a pull-down resistor (Rd = 5.1kΩ from UCPD peripheral) can be activated on PB6, PB4 (UCPD1_CC1,

UCPD1_CC2). The pull-down on PB6 (UCPD1_CC1) is activated by high level on PA9 (UCPD1_DBCC1). The pull-down on

PB4 (UCPD1_CC2) is activated by high level on PA10 (UCPD1_DBCC2). This pull-down control (dead battery support on

UCPD peripheral) can be disabled by setting bit UCPD1_DBDIS=1 in the PWR_CR3 register. PB4, PB6 have UCPD_CC

functionality which implements an internal pull-down resistor (5.1kΩ) which is controlled by the voltage on the

UCPD_DBCC pin (PA10, PA9). A high level on the UCPD_DBCC pin activates the pull-down on the UCPD_CC pin. 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."

After disabling this with UCPD1_DBDIS during initialization, PB4 is only driven to high with any internal pullup.

Only when PB4 is also configured to GPIO output, it has the normal behaviour.

So this pin has some intermediate states between Reset and IO initialization with undesirable influences to peripheral components.

The manual mentioned a further pullup on PB4 in option bytes but it has no effect in STM32G474QE:

Bit 22 PB4_PUPEN: PB4 pull-up enable

0: USB power delivery dead-battery enabled/ TDI pull-up deactivated

1: USB power delivery dead-battery disabled/ TDI pull-up activated

Note: Only for Category 4 devices (otherwise Reserved)

Anything seems to be wrong with PB4 and the overloaded functionality allows not normal use.

I would be grateful if somebody can explain why PB4 is pulled up internally after reset?

[waclawek.jan]

> There is a strange behaviour after reset

So, if I understand it correctly, you observe pullup while the program is already running, correct?

What voltage do you exactly measure? Did you observe the pin using oscilloscope (ie. is it a DC voltage)?

What is in that program? What happens if you write a simple program which goes directly into an infinite loop (i.e. no SystemInit() or similar)?

What hardware is this, is it some "known good" board like Nucleo, or your own?

Do you observe the pullup while NRST pin is held low?

What is the content of GPIO registers and the PB4_PUPEN option bit?

JW

[TDK]

> I would be grateful if somebody can explain why PB4 is pulled up internally after reset?

After reset, PB4 is configured in AF mode as the JTAG_NJTRST pin, with the internal pullup activated.

The pullup should be ~40kOhm, not <10kOhm, but otherwise would explain what you're seeing. An analog reading as JW suggests would yield better info.

[SStor]

Thank you, I discovered now that PB4 is pulled up after reset for NJTRST function.

But PB4 is also controlled by PA10 with pulldown resistor (UCPD dead battery support) and PA10 is a floating input on reset in my application.

So the pulldown resistor on PB4 is switched accidentally by PA10 and causes together with NJTRST pullup resistor intermediate states!

It seems there is a conflict between 2 pin functions on PB4.

It would be an explanation for the behaviour but how can this solved to avoid such states between reset and GPIO initialization?

[waclawek.jan]

> how can this solved to avoid such states between reset and GPIO initialization?

You can't, simply accept it as a fact. Use other pins if this is a problem.

JW

[SStor]

Thank you for your comments.

I think this behaviour with PB4 is not intended by STM and a possible bug in current chip revision.

According erratasheet the NJRST function on PB4 also doesn't work correct and only the newer "category 4" devices STM32G491/4A1 have the additional PB4_PUPEN bit in option bytes obviously.

Now I've solved the problem in my application enforcedly by adding an external pulldown on PA10 to avoid the floating input during initialization, which controls PB4.

Maybe pointing out this problem with PB4 on STM32G4xx family helps other users to avoid same problems already at design...