What do you mean by ccd chip?
At least on the 13 we have at least 2 layers of ocp on all the ports (pd controller and power mux), on the 16 it’s at least 1 (just the pd controller, the 16 uses plain mosfets instead of fancy power muxes).
With you there
That whole thing doesn’t make much sense to me in the first place, it has over 10A of 5v available per side and the other consumers are pretty much negligible so either their “schematics” hide something or this is so they can ride their power limits in other places harder or something. It’s overall pretty weird.
I meant CCG for the cypress chip, not CCD.
At least according to the datasheet it does (though how it is configured is a mystery cause most of that is likely in the pd controller firmware), and in the case of the 13 the power muxes downstream also do (and are connected to just the pd controller which does have to configure them at some point).
Also purely experimentally the ocp on the fw13 is extremely aggressive to the point where it is a problem with a lot of devices that work one every other laptop.
My sample size of laptops is now 2.
One HP laptop.
One Asus laptop:
Both use 1.67V on the CC1
So, the FW16 use of 0.88V seems unique among laptops.
I used the “pdwrite” command with some parameters (setting the 3A Rp resistor to 10k) and made some progress.
the “pdwrite” does the equivalent of (with profile set to 2 for the 3A):
static int cypd_select_rp(int port, uint8_t profile)
We actually get an “ACCEPT” then “GoodCRC” now, so that is progress.
It falls over just a little later though, with no “GoodCRC” to the “GET_SRC_CAP”.
Up until the ACCEPT point the “idle” is at 1.56 V.
But just after the “GET_SRC_CAP”, the “idle” has dropped down to 0.88 V again.
So, I think that is pretty conclusive.
The 0.88 V is causing the problem with some devices.
Setting the 3A Rp resistor to 10k, and thus making the “idle” at 1.56V seems to be the solution to this USB Cycling problem.
Side note: some of the “hold time” , where the Cc output is held at 0V before returning to idle volts, was way below the 1uS minimum limit in the usb spec. That will need fixing also. I measured some at 0.1uS.
EVENT 173173 1 EVENT_ATTACHED 944
DEBUG 173173 1 VBUS:5165, CC:2 945
SRC 173233 1 SOP PD3 s:006 H:0x11A1 (id:0, DR:DFP, PR:SRC) SRC_CAPABILITIES DATA: 2C910127
Option: UNCHUNK DRD USB DRP
[1] Fixed : 5V - 3A
946
SRC 173235 1 SOP PD3 s:006 H:0x11A1 (id:0, DR:DFP, PR:SRC) SRC_CAPABILITIES DATA: 2C910127
Option: UNCHUNK DRD USB DRP
[1] Fixed : 5V - 3A
947
SRC 173237 1 SOP PD3 s:006 H:0x11A1 (id:0, DR:DFP, PR:SRC) SRC_CAPABILITIES DATA: 2C910127
Option: UNCHUNK DRD USB DRP
[1] Fixed : 5V - 3A
948
SRC 173416 1 SOP PD3 s:006 H:0x13A1 (id:1, DR:DFP, PR:SRC) SRC_CAPABILITIES DATA: 2C910127
Option: UNCHUNK DRD USB DRP
[1] Fixed : 5V - 3A
949
SNK 173417 1 SOP s:002 H:0x0281 (id:1, DR:UFP, PR:SNK) GOODCRC 950
SNK 173420 1 SOP PD3 REQUEST s:006 H:0x1082 (id:0, DR:UFP, PR:SNK) DATA: 2CB10412
ObjectPosition:1
GiveBack:0
CapabilityMismatch:0
USBCommunicationCapable:1
NoUSBSuspend:0
UnchunkedExtendedMessagesSupported:0
MaximumOperatingCurrent:3000mA
OperatingCurrent:3000mA 951
SRC 173420 1 SOP s:002 H:0x0161 (id:0, DR:DFP, PR:SRC) GOODCRC 952
SRC 173423 1 SOP PD3 ACCEPT s:002 H:0x05A3 (id:2, DR:DFP, PR:SRC) 953
SNK 173423 1 SOP s:002 H:0x0481 (id:2, DR:UFP, PR:SNK) GOODCRC 954
SRC 173459 1 SOP PD3 PS_RDY s:002 H:0x07A6 (id:3, DR:DFP, PR:SRC) 955
SNK 173460 1 SOP s:002 H:0x0681 (id:3, DR:UFP, PR:SNK) GOODCRC 956
SRC 173567 1 SOP PD3 GET_SRC_CAP s:002 H:0x09A7 (id:4, DR:DFP, PR:SRC) 957
SRC 173569 1 SOP PD3 GET_SRC_CAP s:002 H:0x09A7 (id:4, DR:DFP, PR:SRC) 958
SRC 173570 1 SOP PD3 GET_SRC_CAP s:002 H:0x09A7 (id:4, DR:DFP, PR:SRC) 959
SRC 173573 1 SOP PD3 SOFT_RESET s:002 H:0x01AD (id:0, DR:DFP, PR:SRC) 960
SRC 173574 1 SOP PD3 SOFT_RESET s:002 H:0x01AD (id:0, DR:DFP, PR:SRC) 961
SRC 173576 1 SOP PD3 SOFT_RESET s:002 H:0x01AD (id:0, DR:DFP, PR:SRC) 962
DEBUG 173650 1 VBUS:990: CC:2 963
EVENT 173650 1 EVENT_DETACHED 964
1 Like
Sooooo …
Is this also the cause of cycling with some Anker chargers?
This thread has been all about the Laptop being the power source and the device being the power sink.
The situation is different if the Laptop is the Sink and the device is the Power source. I.e. a Charger. That would have to be covered in a different thread. I don’t have an problem Anker charger, so I cannot work to diagnose that problem.
That being said, curing this problem might actually help the Anker problem, because some CC negotiation happens in both cases.
Umm, maybe, but there is still the requirement to send the GoodCRC signal back to the charger, and if the charger is expecting the signal to be at the 1.56V and it is less than 0.88V then I suspect the same thing is happening as the particular case you have been investigating.
Well, if someone wishes to donate some money to me, I could go and purchase a problematic Anker charger, and do some problem diagnosis on it.
Well, be interesting to know what your current power supply does with your framework as a base line.
I have taken a data scope recording of the FW16 180W PSU being plugged in.
I don’t understand much of it yet, because it uses some SOP Data Types of 16 and 17.
The messages have valid CRC checks and all get GoodCRC responses.
I have not seen USB standard docs that describe them (16, 17) as anything other than “Reserved”.
So, that is why I don’t understand it yet.
I am looking at usb standard doc: “USB_PD_R3_2\ V1.1\ 2024-10.pdf”.
“Table 6.6 Data Message Types”
Anything 16 or above is marked as “reserved”.
Did you look at the resulting voltage levels, or just at the data transfers?
My thinking was more to see if the reduced voltage levels occur when the laptop replies with a GoodCRC message like what you were seeing before. If it does then I suspect that probably is a pointer to the problem with the Anker charger.
This is a image of the FW16 Laptop being connected to the FW 180W PSU with the oscilloscope on the CC1 pin.
I hope you can see that image OK.
The oscillations on the left are what one sees on the FW16 USB-C port before one plugs in a FW16 180W PSU into it.
As you can see, a majority of the level is at 1.6V (during idle time) with a small bit in the middle where it is at 0.88V (during idle time).
If you leave the scope on, you continue to see the occasional pulse of a CC message. This is because, when in EPR mode, it will fall back to SPR mode unless it sees these CC messages.
1 Like
Some points to note about the 22k vs 10k resistor pullup (Rp) and its potential affects on devices.
- 22k results in idle 0.88V. Idle is the voltage between CC messages.
- 10k results in idle 1.6V. Idle is the voltage between CC messages.
- the CC messages swing between 0 and 1.2V
- Current = V / (Rp + Rd)
5V / (22k + 5.1k) = 0.184mA
5V / (10k + 5.1k) = 0.331mA - Current affects noise immunity. More current == better noise immunity. So the 10k case is about twice as noise immune as the 22k case. Note: lot of other factors also affect noise immunity, this is just one of them.
- Using idle of 0.88V makes the detection of the first bit of the CC message difficult to get right. It sometimes adds an extra bit, sometimes drops the first bit.
- Every non-FW laptop I tested with uses the 1.6V idle option. I have only found the FW16 laptop using the 0.88V idle option.
- Every USB device I have negotiates the power using the CC messages. I don’t have any devices that only used the 22k/10k to decide how much power to draw.
- Only USB-C has CC messaging, so the 22k/10k only affects things one plugs into USB-C ports. Those are all normally modern components and thus unlikely to only use the 22k/10k to decide on current draw.
- The CC message detection logic in USB-C chips is normally done in hardware so firmware updates are unlikely to make them better at detecting CC messages. There are a lot of problematic USB-C chips out there.
- When problem cycling devices are instead plugged into USB-A ports, they have worked OK. My theory on that, is that USB-A does not have CC messages, and thus the Rp resistor is not involved at all with USB-A, so those obviously will work. E.g. the problem iPhone noted in other threads. USB-A uses different pins for negotiation messages and also different modulation.
USB-A uses: Frequency Shift Key (FSK) modulation coupled onto the VBUS wire.
USB-C uses: Bi-phase mark code (BMC) encoding onto the CC1/CC2 wire. - I don’t exactly know why the USB-C standard chose BMC. FSK is much better at noise immunity than BMC. It is interesting to note the USB-C supports both. It says all devices must do BMC and FSK is optional, but it might be worth the FW16 falling back to FSK if the BMC negotiation fails.
Summary:
My advice to FW, for design future main-boards, is to design them so that they can all use the 10k Rp and have associated over current protection so if devices draw too much, it will not damage the main-board. This will make the future FW main-boards have better compatibility with a wider range of USB-C devices.
As a work around, but just for me, I will be adding an EC command, so that I can change the Rp on one of the USB-C ports to output idle 1.6V. So that I can connect these problematic cycling USB-C devices to that one port and at least they will connect and not cycle.
3 Likes