FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

STM32G071 UCPD library bug or my bad?

Go to solution
JChau
Associate II

‎2019-07-22 3:04 AM

Hello there, I have a custom board with STM32G071CB for USB Type C PD Source, dual port, RTOS, configured with CubeMX 5.3.0, after writing code on usbpd_dpm_user.c and start debugging, I suspected there are 2+1 strange behavior so I hope somebody can give me some insights why are these happening:

  1. in the code USBPD_SettingsTypeDef.CAD_DefaultResistor is set to 0x00u, from datasheet I am expecting UCPDx.CR.ANASUBMODE should be 1 but what I got from the debugger is 3.
  2. with UCPDx.CR.ANASUBMODE set to 3, UCPDx.SR.TYPEC_VSTATE_CC2 is always 1, even though the type-c connector is n.c.! modified UCPDx.CR.ANASUBMODE to 1 fixed everything (i.e. correct behavior for UCPDx cable detection).
  3. in USBPD_DPM_GetDataInfo I programmed like this:
switch (DataId)
{
  /* Case Port Source PDO Data information */
  case USBPD_CORE_DATATYPE_SRC_PDO :
  *(uint32_t*)(Ptr) = 0x14019032;
  *Size = 4;
  break;
}

I expected this will send a 5V, 500mA fixed source pdo to my usb-pd packet sniffer, that should be

611332900114

, but what i get is 

6103

so I guess something in between my code and the wire filtered my PDO? What's wrong with my code?

Labels:
0 Kudos
This discussion is locked. Please start a new topic to ask your question.
12 REPLIES 12
Go to solution
Dominique
ST Employee

‎2019-07-25 1:36 AM

Hi John,

Yes our system allows to add your own debugging trace, please see below an extract from the user manual

BR

Dominique

0690X000009Z4x4QAC.png

0 Kudos
Go to solution
JChau
Associate II
In response to Dominique

‎2019-07-25 2:57 AM

Hi Dominique,

Please find attached screen capture of USB-PD trace,

I now solved most of the problem and communication with device seems goes smooth, however after device sent a request, from your manual UM2552 USBPD_PE_RequestSetupNewPower should have been called after PE_SRC_TRANSITION_SUPPLY, and I have a debug trace simply write "SetupNewPower" to ensure that function is called, but as seen from the screenshot no such thing is written and break point there is not invoking confirms that function is not called at all, I guess that's why a soft reset/request loop keeps going on without success, can you please provide me some clues why is this happening?0690X000009Z5GLQA0.png

0 Kudos
Go to solution
JChau
Associate II
In response to JChau

‎2019-07-25 8:29 PM

And also after my board as a source sends hardreset with USBPD_PE_Request_HardReset, no USBPD_HR_STATUS_START_REQ callback is received after PE_SRC_HARD_RESET_TIMEOUT.

0690X000009Z6n1QAC.png

And btw I tried forcing a PS_RDY signal by focing SetupNewPower after EvaluateRequest, which in turn calling USBPD_PE_Request_CtrlMessage, but returned with USBPD_FAIL.

0690X000009Z6n6QAC.png

Below is the callback structure generated by STM32CubeMX

  static const USBPD_PE_Callbacks dpmCallbacks =
  {
    USBPD_DPM_SetupNewPower,
    USBPD_DPM_HardReset,
    USBPD_DPM_EvaluatePowerRoleSwap,
    USBPD_DPM_Notification,
    NULL,
    USBPD_DPM_GetDataInfo,
    USBPD_DPM_SetDataInfo,
    USBPD_DPM_EvaluateRequest,
    NULL,
    NULL,
    USBPD_PE_TaskWakeUp,
    NULL,
    NULL,
    NULL,
    USBPD_DPM_EvaluateDataRoleSwap,
    USBPD_DPM_IsPowerReady
  };

Please kindly help if again something is missing at my side, thank you!

0 Kudos
Top