UM2552 message sequence problem

[JChau]

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?
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?
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.

[Dominique]

Hi John

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

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]

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]

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. · Accepted solution]

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]

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?

[ChristophR]

Hi,

In my case I had to call the USBPD_DPM_TimerCounter() and osSystickHandler() function from HAL_TIM_PeriodElapsedCallback():

/**
  * @brief  Period elapsed callback in non blocking mode
  * @note   This function is called  when TIM2 interrupt took place, inside
  * HAL_TIM_IRQHandler(). It makes a direct call to HAL_IncTick() to increment
  * a global variable "uwTick" used as application time base.
  * @param  htim : TIM handle
  * @retval None
  */
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
  /* USER CODE BEGIN Callback 0 */
  if (htim->Instance == TIM2) {
    USBPD_DPM_TimerCounter();
  }
  /* USER CODE END Callback 0 */
  if (htim->Instance == TIM2) {
    HAL_IncTick();
  }
  /* USER CODE BEGIN Callback 1 */
  if (htim->Instance == TIM2) {
    osSystickHandler();
  }
  /* USER CODE END Callback 1 */
}

I completely agree with @JChau​, it is really difficult to figure out what steps are necessary to make the USBPD stack work after generating the code with STM32CubeMX (I used version 5.4.0). I couldn't find anything about that in the software manual UM2552, and also the source documentation is not really helpful. E.g. these comments don't point out that I have to call this function from a timer interrupt periodically:

/**
  * @brief  Initialize DPM (port power role, PWR_IF, CAD and PE Init procedures)
  * @retval USBPD status
  */
void USBPD_DPM_TimerCounter(void)
{

I hope you can either improve the user manual or make STM32CubeMX do a better job in generating working code. Thanks!

Best regards,

Christoph

[Yohann M.]

Hello @Christoph Rüdisser​ 

Thanks for your feedback... We take in account all these remarks to improve our UserManual.

This comment will be taken in account in the next user manual release.

Important point is that our library need a entry point to schedule a timer expiration every 1ms to be able to manage correctly all the PD timers used in the stack and defined in the specifications.

Regards

Yohann