disable hardware GoodCRC for SOP messages in UCPD for Active Cable (EMarker) applications?

[JamesC]

Hello STM32 Community,

I am currently developing a USB Type-C Active Cable application using an STM32 with the official USB-PD Middleware.

My Goal: The MCU needs to behave as an EMarker/Active Cable. Therefore, it should:

1. Ignore all SOP messages on the CC line (no response and no GoodCRC ).

2. Only respond to SOP' and SOP'' messages.

3. Able to monitor (Snoop) SOP messages exchanged between the Source and Sink to maintain state awareness.

The Problem: In the current X-CUBE-USB-PD middleware and STM32CubeMX configuration, there is no explicit option to disable SOP handling while keeping SOP'/SOP'' active. Since GoodCRC is typically handled by the UCPD hardware autonomous logic to meet the strict tTransmitSOP timeout, the hardware automatically sends a GoodCRC when it detects a valid SOP message CRC, even if the firmware isn't intended to process it.

Technical Details & Questions: I am looking for a way to bypass or disable the hardware-level auto-response for SOP only.

1. Register Control: Is there a specific bit in UCPD_CR or UCPD_CFG1/2 that can mask SOP detection while allowing SOP'/SOP''?

   • I noticed the RXORDSETEN bits in stm32g0b1xx.h. If I only enable bits for SOP' and SOP'', will the hardware still generate a GoodCRC for incoming SOP packets?

2. Middleware Bypass: If the hardware doesn't support selective GoodCRC, has anyone successfully implemented a workaround in the USBPD_dpm_core.c or the lower-level stm32xx_it.c to drop SOP packets before the hardware triggers the TX response?

3. Active Cable Mode: Does ST provide a specific configuration or a "Silent SOP" mode for UCPD when the device is defined as a Cable Plug?

Any insights on which registers to manipulate to achieve "SOP silence" would be greatly appreciated.

Thank you in advance!

[FBL]

Hi @JamesC 

Thank you for the question. I'm currently investigating this request and will get back to you ASAP. I checked internally and will get back to you ASAP.

[FBL]

Hi @JamesC  again

I still need to check if there is any viable solution internally

RXORDSETEN is just a convenient way to filter certain types of message, UCPD does allow snooping/monitoring messages destined for the cable like SOP’. 

[FBL]

Hi @JamesC 

If the CC analog function is disabled via ANASUBMODE being disabled, the remaining observation of the line can only be done through an external sensing method such as ADC based polling. This is a workaround, not a supported silent Type-C / EMarker operating mode. 

[JamesC]

Hi @FBL,

Thank you for the update and for checking this internally.

I would like to follow up on one specific point regarding the STM32G071B-DISCO USB-PD Sniffer application.

I noticed that ST already provides a PD protocol sniffer example based on STM32G071B-DISCO, which is able to monitor CC line traffic without actively participating in the PD communication.

Because this seems very close to my Active Cable / EMarker requirement, could you please help clarify a few details?

1. How is the UCPD configured in the sniffer application to avoid interfering with bus traffic?

   • Which registers are specifically configured for this mode?

   • Is it using RXORDSETEN filtering only?

   • Is there any special use of ANASUBMODE, analog disable, or dead-battery / sink/source detach mode?

2. Does the sniffer configuration fully prevent automatic GoodCRC transmission for SOP packets?
   This is the key point for my use case.
   I need to make sure the MCU can observe Source ↔ Sink SOP traffic while remaining electrically silent.

3. Is the sniffer example relying on any external analog sensing path, or is this achieved purely through internal UCPD peripheral configuration?

If the sniffer example already demonstrates a “listen-only” UCPD mode, it would be extremely helpful to understand whether this is the recommended direction for cable applications.

Thank you again for your support.

[FBL]

Hi @JamesC 

The USB PD specification states that cable plugs must meet the receiver requirements for both a Source and a Sink during any transmission using the BMC signaling scheme.

Based on this requirement, we should raise a warning flag: with the current STM32 UCPD behavior, we cannot confidently confirm that the device will satisfy both receiver conditions at the same time for a cable application. Therefore, using this setup as a production cable design carries a risk of non-compliance.

Regarding the USB-PD sniffer example on STM32G071B-DISCO, this example appears to be intended for debug / monitoring purposes and may not be electrically compliant for a cable or eMarker design.

Summary of what the example is doing:

1. Configure the analog path

   • Set ANAMODE = 0
   • Set ASASUBMODE = 0x00 (disabled)

2- Based on demo provided

/* Set the RX dma to allow reception */
  WRITE_REG(hdmarx->CPAR, (uint32_t)&husbpd->RXDR);
  WRITE_REG(hdmarx->CMAR, (uint32_t)ptr_RxBuff);
  hdmarx->CNDTR = SIZE_MAX_PD_TRANSACTION;
  hdmarx->CCR|= DMA_CCR_EN;

  /* disabled non Rd line set CC line enable */
#define INTERRUPT_MASK  UCPD_IMR_HRSTDISCIE  | UCPD_IMR_HRSTSENTIE | \
                        UCPD_IMR_RXORDDETIE  | UCPD_IMR_RXHRSTDETIE | UCPD_IMR_RXOVRIE | UCPD_IMR_RXMSGENDIE

  MODIFY_REG(husbpd->IMR, INTERRUPT_MASK, INTERRUPT_MASK);

  /* Handle CC enable */
//  Ports[PortNum].CCx = cc;
  LL_UCPD_SetccEnable(husbpd, LL_UCPD_CCENABLE_CC1CC2);

  /* Set CC pin for PD message */
  LL_UCPD_SetCCPin(husbpd, cc == CC1?LL_UCPD_CCPIN_CC1:LL_UCPD_CCPIN_CC2);

  LL_UCPD_SetRxMode(husbpd, LL_UCPD_RXMODE_NORMAL);
  LL_UCPD_RxDMAEnable(husbpd);
  LL_UCPD_RxEnable(husbpd);