STM32H573V UCPD CC2 and PC9 interference

[DirkH]

HI,

I am working on a board using STM32H573V and have a working solution with UCPD detecting an inserted memory stick and running the MSC class. In an other part of the software I am using PC9 as an GPIO push-pull, low speed output and as soon as I set it to high, the voltage at PB14 (UCPD CC2) drops from 3.3V to 1.5V and my UCPD handler signals a device attached and turns VBUS on even though nothing is attached. There is no other electrical connection between PC9 and PB14 on the board. I am using a TCPP03-M20 for VBUS switching. The board is acting as VBUS source.

[waclawek.jan]

PC9 is UCPD1_DB2 i.e. part of the dead-battery mechanism ; and as such, gates the pull-down at PB14=UCPD1_CC2.

Set PWR_UCPDR.UCPD_DBDIS bit to disable this behaviour.

JW

[DirkH]

Thank you for the swift reply, Jan ! Problem solved :))

[PR.10]

For future developers having the same wtf moments.
You can call HAL_PWREx_DisableUCPDDeadBattery(), write the registers directly or there is actually a checkbox in the IDE that would saved me hours of investigating ;)

 

[SThom.7]

why is that not made more clear by ST, or better yet disabled by default if you are not using USB!? Not even Cube does this.

I have had a problem on STM32H562 with PB14 (UCPD1_CC2 - FT_c) configured as an open drain output.

the output was not always at the correct level and switching erratically somehow related to QSPI access.

calling HAL_PWREx_DisableUCPDDeadBattery() has fixed the problem.

 

this from the HAL drivers should really be made more clear and explicit elsewhere?

/**
* @brief Disable dead battery behavior.
* @note After exiting reset, the USB Type-C (dead battery) behavior is
* enabled, which may have a pull-down effect on CC1 and CC2 pins.
* It is recommended to disable it in all cases, either to stop this
* pull-down or to handover control to the UCPD (the UCPD must be
* initialized before doing the disable).
* @retval None.
*/
void HAL_PWREx_DisableUCPDDeadBattery(void)