typec/stm32: fix UCPD sink bugs affecting compatibility with newer PD sources#3616
typec/stm32: fix UCPD sink bugs affecting compatibility with newer PD sources#3616michaelajax wants to merge 4 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes STM32 UCPD Type-C sink behavior to improve USB-C PD negotiation reliability and prevent crashes/interrupt storms when interacting with newer PD sources.
Changes:
- Adjust CC attach/orientation detection to consider both CC vstates and treat any non-zero vstate as attached.
- Prevent sending GoodCRC in response to a received GoodCRC.
- Add handling for
RXHRSTDET(hard reset received) to clear the flag and re-arm RX.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
All AI code review comments addressed and manually re-tested against the same 8 USBC PD chargers I tested before. |
I observed that with the B-G474E-DPOW1 devkit, many USB-C PD sources I connected were failing to negotiate PD and some were causing the application to crash.
This PR fixes three issues:
Issue 1: CC cable orientation not detected correctly
The original code had a FIXME noting that CC2 vstate was always 1 on the DPOW1 board, and some code to work in spite of that. The original code guarded against this by pairing
TYPECEVT2with avstate == 3check, which also happened to mask the real attach detection bugs. Since I did not observe the CC2 issue on my board, I restructured the attach logic to check both vstates unconditionally on any CC event, accepting any non-zero vstate.Otherwise, sources advertising Rp_default or Rp_1.5A were silently treated as detach. And, when the cable is in the CC2 orientation,
TYPECEVT1fires as CC1 transitions to 0, butTYPECEVT2may not fire at the same time, the CC2 attach was never detected.Issue 2: RXHRSTDET flag never cleared, causing an interrupt storm
In the event of a hard reset,
RXHRSTDETIEis included inIMR_ATTACHEDbut there was no handler forUCPD_SR_RXHRSTDET.Without clearing it via ICR, the ISR re-enters immediately on every cycle. A handler is added to clearRXHRSTDETCFand re-arm RX DMA so the source capabilities retransmitted after the reset are received.Issue 3: GoodCRC sent in response to GoodCRC
Every successfully received message triggered a GoodCRC, including GoodCRC itself, which the PD spec forbids. Some sources treat this as a protocol error and issue a Hard Reset, which previously triggered Issue 2 above. This change skips the GoodCRC transmission when
header->msg_type == PD_CTRL_GOOD_CRC.Manual Testing
I tested with over half a dozen power supplies from different manufacturers across a wide wattage range, including several newer chargers that support EPR and PD 3.1, and some chargers that have multiple Type-C outputs from a shared power source. All negotiated what I would have expected.
AI Note
Full disclaimer, I leveraged AI tools to debug the issues and implement the fixes along with the manual testing described above. However, I feel the modifications are relatively simple and logical to address the issues I was facing on this board.