Skip to main content
JChau
Associate II
July 29, 2019
Solved

UM2552 message sequence problem

  • July 29, 2019
  • 3 replies
  • 2755 views

Dear members,

This is actually a follow up question to my last one STM32G071 UCPD library bug or my problem, but instead of digging deeper and deeper to an already well answered question, and probably out of topic too, I guess I better start a new one.

  1. In 4.3.4 figure 30, when SRC generates a hard reset, why is this the same as figure 32, Fail to reach vSafe0V during hard reset sequence in SRC? I suppose the final state when SRC generates a hard reset should be returning to Vsafe5V and resend capabilities?0690X000009ZYYjQAO.png0690X000009ZYYeQAO.png
  2. This is the old question not yet answered, I just move it here, both NOTIFY_POWER_STATE_CHANGE and USBPD_PE_RequestSetupNewPower should have been called after PE_SRC_TRANSITION_SUPPLY as shown in Fig. 25 , but in my case nothing is happened, so what am I missing here?0690X000009ZYYtQAO.png0690X000009Z5GLQA0.png
  3. Again another moved unanswered question, when my board as a source generates a hard reset , no USBPD_HR_STATUS_START_REQ callback is received after PE_SRC_HARD_RESET_TIMEOUT as shown in fig 30.0690X000009Z6n1QAC.png
This topic has been closed for replies.
Best answer by Nicolas P.

One important, i suppose your code is correct but anyway I prefer check

File : stm32g0xx_it.c the function shall be like below

void SysTick_Handler(void)
{
 /* USER CODE BEGIN SysTick_IRQn 0 */
 extern void USBPD_DPM_TimerCounter(void);
 USBPD_DPM_TimerCounter();
 /* USER CODE END SysTick_IRQn 0 */
 HAL_IncTick();
 osSystickHandler();
 /* USER CODE BEGIN SysTick_IRQn 1 */
 
 /* USER CODE END SysTick_IRQn 1 */
}

What is the timebase source ? Can you check your timers ?

3 replies

Dominique
ST Employee
July 31, 2019

Hi John

Question 1 : yes this is an error in our documentation, see below the right MSC

0690X000009ZeXhQAK.png

Question 2 : the trace is really strange because you started the MSC of power negotiation however the SINK is still sending REQUEST which is broken the MSC sequence and it is why NOTIFY_POWER_STATE_CHANGE and USBPD_PE_RequestSetupNewPower call never happen

Please could you send me the trace file ? it must be available inside this folder c:\Users\user_name\AppData\Local\Temp\STM32CubeMonitor-UCPD\Acquisition\2019_07_29_15_41_57_USBCPD_Debug_File.cpd

Question 3 : I don't understand the issue it is like PE is no more running or an issue with our internal timer. please could you send me the trace i will check deeper ?

The sink behavior is really strange, please could you share what is the material used as sink ?

BR

Dominique

Dominique
ST Employee
July 31, 2019

Hi John,

Please could you check if the callback has been well initialized ?

inside the function USBPD_DPM_InitCore, check if dpmCallbacks.USBPD_PE_HardReset is not null, value must be equal USBPD_DPM_HardReset

BR

Dominique

JChau
JChauAuthor
Associate II
July 31, 2019

I am quite sure it is USBPD_DPM_HardReset, because USBPD_DPM_HardReset is called with Status==2 as printed in debug trace right after OUT/HRST trace.

Nicolas P.
Nicolas P.Best answer
ST Employee
August 1, 2019

One important, i suppose your code is correct but anyway I prefer check

File : stm32g0xx_it.c the function shall be like below

void SysTick_Handler(void)
{
 /* USER CODE BEGIN SysTick_IRQn 0 */
 extern void USBPD_DPM_TimerCounter(void);
 USBPD_DPM_TimerCounter();
 /* USER CODE END SysTick_IRQn 0 */
 HAL_IncTick();
 osSystickHandler();
 /* USER CODE BEGIN SysTick_IRQn 1 */
 
 /* USER CODE END SysTick_IRQn 1 */
}

What is the timebase source ? Can you check your timers ?

JChau
JChauAuthor
Associate II
August 1, 2019

Yes I confirmed that adding USBPD_DPM_TimerCounter(); into my timer base resolved both my problem 2 and 3, SetupNewPower(), PS_RDY, also correct hard reset behaviour can now be observed, big thanks to Dominique and Nicolas for all your kind help!

And I must point out that neither USBPD_DPM_TimerCounter(), USBPD_DMA_PORT0_IRQHandler(), and also USBPD_DMA_PORT0_IRQHandler() is auto-generated from STM32CubeMX nor they are mentioned in UM2552 (unless I missed it, but I did a text search in the PDF and found nothing), so it is easy to be missed unless someone is reading the example source code very carefully, just a suggestion but I guess this can be improved easily?