X-CUBE-USB-PD problem, doesn't recognize the cable detachment.

Y.Nomura · ‎2020-07-02

I am developing an X-CUBE-USB-PD system that works with the STM32G070CB and FUSB307B.

It is based on an example project for the FUSB307BGEVB, which behaves as a DRP.

The library I'm using for it is M0_PD3_FULL.

When the device behaves as a source, unplugging the cable after the state shifts to PE_STATE_READY_WAIT does not cause a detach event.

After this, the device will not respond to anything. However, it does not appear that a HardFault has occurred. The alert is left in place as it occurs.

However, if you put a breakpoint in the handler of the alert detection, it works fine.

That leads me to believe that the problem is related to something timing related.

What could be the possible cause of such a problem?

Y.Nomura · ‎2020-07-03

Hi Yohann

I found the cause of the problem.

The power supply was the cause.

As soon as I unplugged it, the DCDC converter on the 5V line was outputting an overvoltage.

This would cause the DC converter on the 3.3V line to be temporarily disabled.

Maybe the FUSB307B couldn't be accessed while the voltage on the 3.3V line was down. I think so.

Thank you for your help so far.

3.3V line when unplugged from the USB plug (Power supply for FUSB307 and MCU)

View solution in original post

Yohann M. · ‎2020-07-02

Dear @Y.Nomura

I take the opportunity to tell you that it is possible to provide directly the PD trace (.cpd file). This file is automatically generated by CubeMonitor-UCPD and available in the following folder:

* C:\Users\<your_login>\AppData\Local\Temp\STM32CubeMonitor-UCPD\Acquisition

For deeper analysis, you could attach this file in the thread. (I advise you to close cubemonitor before saving the file)

Did you try to break the code after detecting that the detach did not occur?

Then if you break in this part of code when you detach the cable, it will be fine to know if you managed to read the alert register.

Is it possible to provide a log without breaking the application? You should have further logs thanks to debug traces available in our component fusb305:

USBPD_StatusTypeDef fusb305_tcpc_alert(uint32_t Port, uint16_t *Alert)
{
  USBPD_StatusTypeDef usbpd_status = USBPD_OK;
  
  /* Read the Alert register from the TCPC */
  usbpd_status = USBPD_TCPCI_ReadRegister(Port, TCPC_REG_ALERT, (uint8_t*)&state[Port].Registers.Alerts.word[0], 2);
 
  /* Read the Alert register from the TCPC */
  usbpd_status = USBPD_TCPCI_ReadRegister(Port, TCPC_REG_ALERT_VD, (uint8_t*)&state[Port].Vendor.ALERT_VD, 1);
 
  *Alert = state[Port].Registers.Alerts.word[0];
#if defined(TCPM_OLD_TRACE)
#if defined(_TRACE)
  {
    uint8_t tab[15] = {0};
    sprintf((char*)tab,"Alert=%2x", *Alert);
    FUSB307_DEBUG_TRACE(Port, FUSB307_DEBUG_LEVEL_1, tab);
  }
#endif /* _TRACE */
#else
  FUSB307_DEBUG_TRACE(Port, FUSB307_DEBUG_LEVEL_1, TCPM_TRACE_ALERT_READ_ALERT, Alert, 2);
#endif /* TCPM_OLD_TRACE */

Regards,

Yohann

Y.Nomura · ‎2020-07-02

Hi Yohann.

I followed your advice and logged the traces.

I have prepared a log with and without breakpoints.

Thanks for your help.

Yohann M. · ‎2020-07-02

Hi

* no_break_points.cpd

I can see an alert after 2 secs which may link to detach event but ALERT read in FUSB307 register returns 0. It means there are no pending alert !? I would expect to have at least 'ALERT=1' which means CC status change.

-pe - 0000008717 P0 PE_STATE_READY_WAIT

debug 0000010062 P0 DEBUG0 "TCPM ALERT "

debug 0000010062 P0 DEBUG0 "Alert= 0 "

* with_break_points.cpd

In this trace, I can see clearly the detach after 7secs. For me, in this log, you managed to detach cable.

Do you mean that you put the breakpoint and then you ran again the application? In this case, you saw the detach?

-pe - 0000041623 P0 PE_STATE_READY_WAIT

debug 0000048548 P0 DEBUG0 "TCPM ALERT "

debug 0000048548 P0 DEBUG0 "Alert=203 "

debug 0000048554 P0 DEBUG0 "state=0 "

debug 0000048555 P0 DEBUG0 "Vbus= 0 "

debug 0000048555 P0 DEBUG0 "VbusVolt=0 "

debug 0000048555 P0 DEBUG0 "tcpc_set_pin_role(DIS, RD)"

==== 0000048556 P0 EVENT_DETACHED ====

I never detected such issues. For tests, you try to add a delay in 'fusb305_tcpc_alert' function and check if you are able to read a status change in alert register:

USBPD_StatusTypeDef fusb305_tcpc_alert(uint32_t Port, uint16_t *Alert)
{
  USBPD_StatusTypeDef usbpd_status = USBPD_OK;
 /***/
  /* Start a delay before reading ALERT register */
  USBPD_TCPCI_Delay(1); // 1ms, you could increase it step by step  
/***/
 
  /* Read the Alert register from the TCPC */
  usbpd_status = USBPD_TCPCI_ReadRegister(Port, TCPC_REG_ALERT, (uint8_t*)&state[Port].Registers.Alerts.word[0], 2);