[V1.79.6 Build 200208] CT-2 does not GoodCRC PD3.0 Get_Source_Cap_Extended message
Edited by TestUSBC at 24-03-2020 07:16Hello,CT-2 with firmware does not send GoodCRC response to PD3.0 Get_Source_Cap_Extended message.
This can be verified with iPad Pro 2018 with 13.3.1 firmware using PD Trigger Mode functionality.
will loop repeatedly and disconnect.
Likely the CT-2 is only looking at 4 bits of header VDO in PD3.0.
This will cause misinterpreting "Get_Source_Cap_Extended" as a "GoodCRC" message, etc.
This can be observed by looking at first 5 bytes of "Header" VDO in USB-IF PD3.0 specification.
In PD2.0 version of spec, only 4 bytes were used. In PD3.0, 5 bytes are used.
PD3.0 Spec
6.2.1.1 Message Header
Table 6-1 Message Header
(Bits 4...0) in (6.3 Control Message)
00001 GoodCRC
10001 Get_Source_Cap_Extended
-----
00010 GotoMin
10010 Get_Status
-----
00011 Accept
10011 FR_Swap
(etc)
Please make a patch/fixed firmware for CT-2 to correct this iPad Pro 2018 problem.
Hey, thanks for your feedback.
I fixed it by recognizing 5 LSB bits instead of 4.
And messages I cannot recognize are sent back with "1 0000 Not_Supported".
The firmware is in the attachment(Use a u-disk upgrade method to apply).
Could you please flash the firmware to see if the problem is fixed (I don't have iPad 2018, any devices having that behaviour neither.)?
Thank you for test firmware.
I will try and write back. The test firmware is not complete. Not_Supported response is sent *before* GoodCRC, which causes protocol errors. Not_Supported may also not be a valid response. Some proper responses are mandatory.
PD2.0 and PD3.0 require different rules. For same message PD2.0 may need "Reject" while PD3.0 may need "Not_Supported". See (PD2.0 6.10 Message Applicability) vs (PD3.0 6.12 Message Applicability).
I suggest properly populate all response to all messages. Otherwise may cause protocol errors with various devices. Make sure fields such as Comm_Cap and Unconstrained_Power match in Request, SrcCap, SinkCap responses as well. Otherwise iPad will not enable USB data in some situations. Looking at trace more closely, GoodCRC is sent by Apple iPad in response to Not_Supported reply. But CT-2 is not sending GoodCRC in response to Get_Source_Cap_Extended request.
Why is CT-2 not issuing GoodCRC reply to Get_Source_Cap_Extended packet....? It is sending Not_Supported reply, so can hear message. But is not giving GoodCRC to ACK transmit.
I am unsure if is polite to ask what PD PHY chip is used in CT-2. I took mine apart but did not remove LCD to see below. I think PD PHY chip may have a bug, and may need firmware update. static/image/common/user_online.gif TestUSBC static/image/common/clock.gif 25-03-2020 18:44
Looking at trace more closely, GoodCRC is sent by Apple iPad in response to Not_Supported reply. But ...
PD PHY is FUSB302. It handles very little just in the bottom layer. So it is more likely my firmware fault. Let me examine later. static/image/common/user_online.gif TestUSBC static/image/common/clock.gif 25-03-2020 18:44
Looking at trace more closely, GoodCRC is sent by Apple iPad in response to Not_Supported reply. But ...
Yeah I noticed that in both cases (When I reply with "Not_Supported" or I simply don't replay anything.), PD PHY didn't send a GoodCRC message. I suspect that as the PD PHY is released when only PD2.0 is available, it only calculate the CRC with valid bits. Extended bit in message header is not defined in PD2.0, and PD2.0 forces this bit to be 0. This might caused undefined behavior inside the chip.
By the way, PD PHY is configured to send a GoodCRC message automatically after receiving and checking any massage. And it is also configured to interrupt the uC when a message with correct checksum is received. So we face a CONFLICTION, it didn't send back a GoodCRC, meaning it thinks there is something WRONG in the message. However, the uC is interrupted, meaning that the message IS ACTUALLY CHECKED CORRECTLY. I guess there is a bug in the chip, it's not designed for PD3.0 in the first place.
Anyway, if it is so, a possible workaround is to send a GoodCRC message manually if the message is extended. Firmware in the attachment probably solved the problem.
Sorry for slow reply. No further data as may have SARS-CoV-2 so am moving to isolation soon.
Thank you yanke928 for the fw in 7#. Manual GoodCRC (1.137ms) is barely within tReceive limit (0.9-1.1ms max) for CRCReceiveTimer. Be warned some devices (0.9ms) may not tolerate.
Fix seems to work and iPad does not loop. Issue is fixed. Thank you and well done. I hope am able to work with you in future.
页:
[1]