STM32H573 PB14

[gaso111]

In our project I use STM32H573VIT6 LDO uC.

We have a problem with the PB14 pin. We use 3 pins for LED control (PB10, PB13 and PB14, see photo). The problem with the PB14 is that the LED lights up dimly without code initialization.

If PB14 is initialized as Output, Open Drain, No Pullup-Pulldown, it lights up dimly in the OFF state and normally in the ON state.

With Output Push-Pull initialization it works normally, i.e. in the OFF state the LED does not light up and in the ON state it lights up normally.

 

1. What could be the problem?

2. Should I use PB14 at all and is there a potential risk of later problems?

[Imen.D]

Hello @gaso111 ,

Welcome to the Community :)

Please take in consideration the STM32H5 characteristics and limitation mentioned in this FAQ: SPI maximum clock frequency for STM32H5 MCUs devic... - STMicroelectronics Community

[Tesla DeLorean]

I'd have to say the Data Sheet does a very poor job explaining WHY PB13/PB14 behave oddly. Inference very low sink/source current (1-2mA)

I understand the PC13,14,15 issue where they are on some low power domain.

If the pin's basically floating (OD, HIGH), how can it be leaking enough current that the LED illuminates?

Is the issue here that the LED usage has damaged the part already?

[gaso111]

Hello @Tesla DeLorean 

You said:

"Inference very low sink/source current (1-2mA)"
Where did you get this information from?

 

"Is the issue here that the LED usage has damaged the part already?"

I don't think, because the same effect is if uC is not flashed (board is ohnly powered).

 

 

 

[STOne-32]

Dear @gaso111 ,

I concur what described by @AScha.3  the electronic shared should LED On when GPIO is in output 0 level to GND , either OD or Strong Push-Pull to 0 ( which seems working) . If possible to probe PB13 and PB14 and show us the signals in different combinations. These two GPIOs are special for USB type C _c as shared by @Tesla DeLorean  and @Imen.D  . We need to understand what is happening with PB14 only as it seems a path / strong leakage is created to ground even in input default state . Also sharing full schematics of power pins and boot is helpful. Let us know 

Ciao,

STOne-32

[gaso111]

---

@STOne-32 wrote:

Dear @gaso111 ,

I concur what described by @AScha.3  the electronic shared should LED On when GPIO is in output 0 level to GND , either OD or Strong Push-Pull to 0 ( which seems working) . If possible to probe PB13 and PB14 and show us the signals in different combinations.

No pulses, on Pin PB14 I measured (with scope) 1,38V and on other side of resistor R213 I measured 1,50V

That means current flowing in PB14, when OD output is not active (FET is not conductive) is:

(1,50-1,38)/470=0,25mA

On PB13 I measured 1,86V and on other side of R210 the same voltage 1,86V. This means no current flows in PB13 pin.

These two GPIOs are special for USB type C _c as shared by @Tesla DeLorean  and @Imen.D  . We need to understand what is happening with PB14 only as it seems a path / strong leakage is created to ground even in input default state . Also sharing full schematics of power pins and boot is helpful. Let us know 

Ciao,

STOne-32

P.S.

I have uploaded part of the schematic. There is VBAT (pin6)  open. I connected it to VDD (3V3) and a 100nF capacitor in parallel, but no changes, LED201 lights up dimly when PB14 is not active (in OD mode).

 

---

 

[AScha.3]

So the bootloader is started and sets PB14 as uartTX :

ed: as SPI2 output :

 

When you have flashed a valid program and dont start the bootloader, (boot0 = lo ),

but your program, PB14 will work as you want.

[STOne-32]

Dear @gaso111  @AScha.3 

 

Is that possible to not leave PC9 GPIO floating and try to connect it to Ground or VDD, just for testing purposes to see if the PB14 behavior still the same ?   The hypothesis may be the USB-PD Battery dead function is taking the control by default.   Let us know.

STOne-32.

[AScha.3]

Dear @STOne-32  ,

i tried PC9 -> GND : LED dark, also on hard reset . 

And in my program i use SDMMC , PC9 here with pullup (and sd-card D1 ), PC9 at 3.3V : LED lights up dimly .

So there is an undocumented hardware, independent from cpu (run, reset ), that switches a 12Kohm pulldown on PB14 , if PC9 is not at GND .

Is this then an addition to the errata or for the datasheet ? Now its not documented , afaik.

[STOne-32]

Dear @AScha.3 ,

 

More information are here Introduction to USB Type-C® Power Delivery for STM32 MCUs and MPUs - Application note on Battery dead function when the MCU is not powered with CC1/CC2 and DBCC1/DBCC2 pins ( additional functions) that present that Rd value of 5.1Kohm.  We will be back to you with more details to clarify the I/Os states after reset for these particular ones.

Cheers,

STOne-32.

[covejstewart]

PB14 is part of the USB Power Delivery peripheral and implements a pulldown for dead-battery detection, which is present even when your part is powered off / uninitialized.  

When your system boots, you can disable it by calling HAL_PWREx_DisableUCPDDeadBattery();

Similar thread: https://community.st.com/t5/stm32-mcus-products/stm32h573v-ucpd-cc2-and-pc9-interference/td-p/857031