USB PD: MCU may not send GoodCRC back to PD compliant partner

[intercreate]

Describe the set-up

• https://www.st.com/en/evaluation-tools/nucleo-g071rb.html
• arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

Describe the bug USB PD uses the CC line bidirectionally. The spec says that the sender must give up the line within 23uS (tEndDriveBMC) after the end of the frame.

The STMicro library, at least when used with a bare-metal codebase, seems to check the bus at around 10uS.. and only checks it once. If the bus is busy, it just throws the packet away.

This is catastrophic since this can happen when trying to send a GoodCRC message.

How To Reproduce

1. Find port partner source who gives up the bus close to tEndDriveBMC time. The https://www.st.com/en/evaluation-tools/p-nucleo-usb002.html is about 17uS and is a good candidate.
2. Configure the STM32G0 as a SNK.
3. Using a PD sniffer, observe lack of GoodCRCs

Additional context This patch below keeps me moving forward. However, I think a better solution is to place a 23uS delay after message received to guarantee that the firmware won't check the CC bus too early.

--- a/Middlewares/ST/STM32_USBPD_Library/Devices/STM32G0XX/src/usbpd_hw_if_it.c
+++ b/Middlewares/ST/STM32_USBPD_Library/Devices/STM32G0XX/src/usbpd_hw_if_it.c
@@ -51,6 +51,7 @@ void PORTx_IRQHandler(uint8_t PortNum)
   UCPD_TypeDef *hucpd = Ports[PortNum].husbpd;
   uint32_t _interrupt = LL_UCPD_ReadReg(hucpd, SR);
   static uint8_t ovrflag = 0;
+  static uint8_t tx_retry = 0;^M

   if ((hucpd->IMR & _interrupt) != 0u)
   {
@@ -59,7 +60,14 @@ void PORTx_IRQHandler(uint8_t PortNum)
     {
       /* the message has been discarded */
       LL_UCPD_ClearFlag_TxMSGDISC(hucpd);
-      CLEAR_BIT(Ports[PortNum].hdmatx->CCR, DMA_CCR_EN);
+      if(tx_retry != 2) {
+        tx_retry++;
+        LL_UCPD_SendMessage(Ports[PortNum].husbpd);
+      }
+      else {
+        tx_retry = 0;
+        CLEAR_BIT(Ports[PortNum].hdmatx->CCR, DMA_CCR_EN);
+      }
       return;
     }

[ALABSTM]

Hi @intercreate,

Welcome back. Please, let me introduce @NPESTM from our development teams. He will take in charge checking the relevance of what you reported and provide you with his feedback.

With regards,

[NPESTM]

Hello. We have improved this part already. However our correction is wider. We cannot check for the moment if we solved your issue because of Covid. Once we can find the board setup, we will check if the new version of the library also solves your issue

[intercreate]

Hi @NPESTM . Glad to see! I'm looking forward to the next STM32CubeG0 release.

[ALABSTM]

ST Internal Reference: 81830

[ALABSTM]

Hi @intercreate,

The fix of this issue is available in the frame of the v1.4.0 released a few minutes ago on GitHub.

With regards,