Should BSP_USBPD_PWR_VBUSOff() and BSP_USBPD_PWR_VBUSOn() of the USBPD library block until the VBUS voltage is ok?

[ChristophR]

Hi,

We try to implement a DRP device with the USBPD library on a STM32G071 uC.

From the documentation the requirements for the following functions are not clear:

BSP_USBPD_PWR_VBUSOff():

- Should it block until VBUS < USBPD_PWR_LOW_VBUS_THRESHOLD?

- What is the maximum allowed blocking duration? In the PD standard the spec for tSafe0V is max 650ms.

BSP_USBPD_PWR_VBUSOn() & BSP_USBPD_PWR_VBUSSetVoltage_Fixed() in source operation:

- Same as above, should these functions block until the VBUS voltage is settled or should they return immediately?

- What is the maximum allowed blocking duration? Spec for tSrcTurnOn is max 275ms in the PD standard, tSrcReady is max 285ms.

- Note, if it returns immediately, the hard resets do not work, since USBPD_PWRR_IF_SupplyReady() is called only once, and VBUS is not > USBPD_PWR_HIGH_VBUS_THRESHOLD at this time. See the attached screenshot.

 

USBPD_DPM_UserCableDetection():

- Only in one example (DemoUCPD) I saw a delay before enabling VBUS. In the USB-PD_Provider_1port example there is no delay. Is this delay required?

void USBPD_DPM_UserCableDetection(uint8_t PortNum, USBPD_CAD_EVENT State)
{
 ...
 case USBPD_CAD_EVENT_ATTACHED:
 ...
	if(USBPD_PORTPOWERROLE_SRC == DPM_Params[PortNum].PE_PowerRole)
 {
 USBPD_DPM_WaitForTime(110); // <-------------------
 if (USBPD_OK != USBPD_PWR_IF_VBUSEnable(PortNum))

We are using CubeMX to generate the basic skeleton with the following libs:

- FW pack STM32Cube_FW_G0_V1.5.1

- USBPD core library V4.0.0

- USBPD device library V3.3.1

Thanks!

BR, Christoph

[Guenael Cadier]

Hello @Christoph Rüdisser​ 

All functions in BSP are board dependent, so might have to be adapted depending on your HW capabilities et specifications. I would say it is better to exit VBUS management functions when the request is served.

So aside of max delays on SW side, HW should also be able to fulfill those timing constraints.

Some timing constraints as listed in Power Delivery specs :

tSrcTurnOn and tSrcReady are similar max expected durations :

• tSrcTurnOn for transition from 0 to 5V
• tSrcReady for other voltages transitions (when a new PDO is selected)

For some procedures, as power role swap, Hard reset, ... VBUS is expected to go back to 0 at some point in time. Here again it could be implemented in different ways on application side, either fixed delays or adaptative wait until a given VBUS voltage is reached.

That's why BSP and DPM parts are provided as examples by ST, but surely need to be adapted to your needs.

Regards

Guenael

[ChristophR]

Hi @Guenael Cadier​ 

Thanks for your quick response.

What do you mean with "exit VBUS management functions when the request is served"? 

E.g. for BSP_USBPD_PWR_VBUSOff(), should it block until VBUS < USBPD_PWR_LOW_VBUS_THRESHOLD? Or should it just open the VBUS FETs and start to discharge?

And what about my last question regarding USBPD_DPM_UserCableDetection(). Is the USBPD_DPM_WaitForTime(110) required as in the DemoUCPD example? I guess there is a reason why it was added in the demo code, but it's missing in other examples. And with the core library being closed source and the incomplete documentation, there is no way for me to figure it out by myself.

BTW, will there be a new version of the UM2552 soon? I'm still working with the outdated Rev 2 from October 2019. 

Thanks,

Christoph

[ChristophR]

Hi @Nicolas P​ 

could you maybe have a look at my questions above?

Thanks!

Christoph

[Nicolas P.]

Hello @Christoph Rüdisser​ 

3 questions raised by you :

1- What do you mean with "exit VBUS management functions when the request is served"? E.g. for BSP_USBPD_PWR_VBUSOff(), should it block until VBUS < USBPD_PWR_LOW_VBUS_THRESHOLD? Or should it just open the VBUS FETs and start to discharge?

=> For VBUSOff, You need to open the FETs, discharge, until the VBUS is under USBPD_PWR_LOW_VBUS_THRESHOLD.

2- And what about my last question regarding USBPD_DPM_UserCableDetection(). Is the USBPD_DPM_WaitForTime(110) required as in the DemoUCPD example?

=> No you can remove it.

3-BTW, will there be a new version of the UM2552 soon? I'm still working with the outdated Rev 2 from October 2019. 

=> Yes, the plan is to update it when we will release the EPR stack update. Q1 2023.

Regards,

Nicolas

[ChristophR]

Hi @Nicolas P​ 

Thanks for your response! Could you please also answer the open questions from my first post?

BSP_USBPD_PWR_VBUSOn() & BSP_USBPD_PWR_VBUSSetVoltage_Fixed() in source operation:

Should these functions also block until the VBUS voltage is settled or should they return immediately?

BSP_USBPD_PWR_VBUSOn() & BSP_USBPD_PWR_VBUSSetVoltage_Fixed(), BSP_USBPD_PWR_VBUSOff():

What is the maximum allowed time to wait for the voltage to be settled? I understand the requirements from the PD standard, but I guess that the stack also needs some time. So I guess I'm not allowed to block for the whole tSrcTurnOn or tSrcReady durations.

Proposal: I'd really like to see such important stuff in the function documentation. This would safe your customers a lot of trouble and time. Currently the documentation looks like the example below. This kind of documentation is basically useless. It doesn't mention if this function is for source or sink operation, there is nothing mentioned about timing requirements, and if I have to block until the voltage is settled.

/**
 * @brief Enable power supply over VBUS.
 * @param Instance Type-C port identifier
 * This parameter can be take one of the following values:
 * @arg @ref USBPD_PWR_TYPE_C_PORT_1
 * @arg @ref USBPD_PWR_TYPE_C_PORT_2
 * @retval BSP status
 */

Thanks & BR,

Christoph

[Guenael Cadier]

Hi @Christoph Rüdisser​ 

Regarding your questions, about BSP_USBPD_PWR_VBUSOn() & BSP_USBPD_PWR_VBUSSetVoltage_Fixed(), it is important is that voltage is as requested, at the end of the voltage configuration step (This would be used either for VBUS management on CAD events by DPM, or through the USBPD stack callback USBPD_DPM_SetupNewPower() that will be executed on some specific procedures as PR Swap, Hard reset, ...).

Regarding timing constraints, timing provided in specs concern the whole procedure, i.e. from a CAD event or a PD message, till the completion of the requested procedure. I have no precise figure about the time spent in Stack execution but basically, from event till callback execution, the time spent will be 1 or 2 ms max till application code (DPM or PWR IF functions) are called. So max time constraint applies basically to execution of user code (you should be able to check timestamps of trace events in UCPD Monitor trace to evaluate spent time).

I agree current documentation is lacking some useful explanations. This is to be improved, for sure.

Hope this helps anyway.

Best regards