Uploading my test vid with ZY1280E tester but I don’t think there’s anything useful
3 Likes
The last message before break off seems to be that laptop (according to the color of the bolt symbol, green suggests that blue is device side and green is charging side) is suggesting power role swap, but (unsure) iPhone refused by breaking off the connection (control message 1dac, where the last 5 bits 01010 is PR_swap). I will test it against another devices (including another USB-C device and another laptop) and see whether this message could happen.
1 Like
Now I tried to capture USB PD signals using a peeled USB-C cable and a logic analyzer:
Seems like the laptop does not ack to the message asking about battery capability.
And tried to send soft reset, but no response
Finally a hard reset message is observed, and that’s probably what causes to power cycle
On comparison with Dell XPS, it acks the message and returns that this feature is unsupported.
I cannot upload sigrok capture here, so I am putting it on my Google Drive. The log also comes with other captures to a charger and to a desktop PC. EDIT: To make fair comparison, I added USB-PD capture for a Dell XPS 13 to iPhone 15 Pro Max into the zip file
Hopefully someone with USB-PD knowhow knows what is happening here.
EDIT2: turns out sigrok decoder GitHub - sigrokproject/libsigrokdecode: Read-only mirror of the official repo at git://sigrok.org/libsigrokdecode. Pull requests welcome. Please file bugreports at sigrok.org/bugzilla. is not able to decode USB PD Revision 3.2 properly, as some of the extended data are wrongly decoded. I am trying to work on the decoder so it is updated to the standard.
EDIT3: updated with the partially patched sigrok decoder
5 Likes
Great investigation, now that makes me wonder that if AMD13(16 too?)'s compatibility issue on certain external SSD might be related to power delivery to the enclosure, rather than what’s processing the data being transferred.
4 Likes
It seems to me that the FW will receive and send USB-PD messages. We need some way to log all those messages in the FW. I.e. log all the CC pin messages and also some ADC to measure the Voltage and Current on the Vconn and Vbus pins.
Does anyone know how to do that?
In linux one can install “modprobe usbmon” and then use wireshark, but I think that only captures USB URB messages and none of those have anything to do with power.
I am new to USB-PD, so only read this so far:
It also talks about the USB cables reporting what amount of power they can carry.
I have seen log messages like this, so maybe the problem also might be related to the cables used.
[ 1595.155477] ucsi_acpi USBC000:00: unknown error 0
[ 1595.155496] ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
I can only assume from that, that I have a cable that does not report its capabilities.
Interestingly, the above ucsi_acpi message is due to the power cable provided by the FW power brick.
Obviously the FW provided power brick works and provides power, so maybe it would be worth trying to get the FW to log all the USB-PD messages from that first and check it is doing it correctly, and then move to analysing a non-working device like the iPhone 15.
Another approach would be for someone to obtain a certified usb-pd spec tester, plug it into the FW13/16 and see if it fails any tests.
I think it is documented that the latest 3.03 firmware for the FW16 fixed some aspects of usb-pd to make it more compatible with a wider variety of power bricks. Maybe there is still more work to do?
I’m only seeing those when I have the USB-A extension cards inserted (as reported here). Are you getting them with just USB-C?
I’m not sure whether this is the correct source I should look into for PD handling:
@DHowett i think the log printed in the source code above can be shown on the debug console using your CCD expansion card, is it possible for me to get one of these or better I try making one? I am in Taiwan.
1 Like
The following is from the EC log by making a “closed case debugger” using @DHowett 's information:
[73.683200 CYPD_RESPONSE_PORT_CONNECT 3]
[73.751100 CCG_RESPONSE_VDM_RX]
[73.807500 CYPD_RESPONSE_PD_CONTRACT_NEGOTIATION_COMPLETE 3]
PORT80: 0227
PORT80: 0227
PORT80: 021A
ec:~$ E: Reset i2c port20 fail! Bus might be stalled.
[76.05330E: Recover Bus failed
0 cypd_read_reg_E: Recover Bus failed
block failed: ctE: Recover Bus failed
E: Recover Bus failed
rl=0x1, reg=0x2008]
[76.054400 CYP5525_PD_STATUS_REG failed]
[76.056700 cypd_read_reg_block failed: ctrl=0x1, reg=0x2008]
[76.057700 CCG_PD_STATUS_REG failed]
[76.060000 cypd_read_reg8 failed: ctrl=0x1, reg=0x200c]
[76.061000 CCG_TYPE_C_STATUS_REG failed]
[76.063300 cypd_read_reg_block failed: ctrl=0x1, reg=0x2010]
[76.065200 cypd_read_reg_block failed: ctrl=0x1, reg=0x2014]
[76.864300 Battery 63% (Display 62.6 %) / 2h:0 to empty]
[76.927100 PD1 Reset Complete]
[76.929000 CYPD 1 is in bootloader 0x0094]
[76.930400 CYPD bootloader reason 0x8000]
[76.957000 CYPD 1 is in bootloader 0x0094]
[76.958500 CYPD bootloader reason 0x8000]
[76.984900 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[76.986600 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[76.988200 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[76.989800 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[76.991400 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[76.993000 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[76.994600 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[76.996200 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[76.997800 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[76.999400 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.001000 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.002600 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.004200 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.005800 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.007400 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.009000 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.010600 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.012200 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.013800 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.015400 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.017000 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.018600 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.025100 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.030500 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.036000 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.042200 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.047700 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.053100 cypd_read_reg8 failed: ctrl=0x1, reg=0x00]
[77.060300 PD1 Reset Complete]
[77.064100 Controller 1 App1 version B:3.7.0.D0 , AP:0.0.1C]
[77.068700 Controller 1 App2 version B:3.7.0.D0 , AP:0.0.1C]
[77.086500 cypd_update_power_status:1=0x8]
[77.090000 C1, cypd_set_power_state pwr state 0]
[77.107500 CYPD 1 Ready!]
[77.140600 cypd_write_reg8_wait_ack C:0 0x1004 response 0xd]
[77.142000 SET CCG_SELECT_REG failed]
[77.153400 cypd_write_reg8_wait_ack C:0 0x2004 response 0xd]
[77.154800 SET CCG_SELECT_REG failed]
PORT80: 0227
[77.665500 CYPD_RESPONSE_PORT_CONNECT 3]
[77.733800 CCG_RESPONSE_VDM_RX]
[77.790000 CYPD_RESPONSE_PD_CONTRACT_NEGOTIATION_COMPLETE 3]
PORT80: 0227
PORT80: 0227
Normal response looks like:
[425.209900 CYPD_RESPONSE_PORT_CONNECT 3]
[425.277300 CCG_RESPONSE_VDM_RX]
[425.288200 CCG_RESPONSE_VDM_RX]
[425.506200 CYPD_RESPONSE_PD_CONTRACT_NEGOTIATION_COMPLETE 3]
[425.519300 Battery 60% (Display 59.9 %) / 2h:24 to empty]
PORT80: 0227
[425.572200 CCG_RESPONSE_VDM_RX]
[425.620700 CCG_RESPONSE_VDM_RX]
[425.669300 CCG_RESPONSE_VDM_RX]
[425.718000 CCG_RESPONSE_VDM_RX]
[425.766500 CCG_RESPONSE_VDM_RX]
[425.814500 CCG_RESPONSE_VDM_RX]
[425.862900 CCG_RESPONSE_VDM_RX]
[425.911500 CCG_RESPONSE_VDM_RX]
[425.960100 CCG_RESPONSE_VDM_RX]
[426.008700 CCG_RESPONSE_VDM_RX]
[426.056800 CCG_RESPONSE_VDM_RX]
[426.104900 CCG_RESPONSE_VDM_RX]
[426.153400 CCG_RESPONSE_VDM_RX]
[426.202100 CCG_RESPONSE_VDM_RX]
[426.250700 CCG_RESPONSE_VDM_RX]
[426.298900 CCG_RESPONSE_VDM_RX]
[426.347000 CCG_RESPONSE_VDM_RX]
[426.395600 CCG_RESPONSE_VDM_RX]
PORT80: 0227
[427.199200 CYPD_RESPONSE_PD_CONTRACT_NEGOTIATION_COMPLETE 3]
I suspect there’s a firmware bug in the PD controller that caused a hang during handshaking.
7 Likes
In this direction, I just received a “cheapish” USB-C Monitor for traveling ( Arzopa 16.1 ''144hz 1080p fhd . Here I also get some ucsi_acpi error when the monitor is only connected to the laptop through usb-c and the monitor briefly powers up, but then does not receive a signal. With a Fairphone 4 and Thinkpad T490 this mode works. So probably something between deciding the PD-mode and the USB-C alt modes gets stuck…
[ 1387.041716] ucsi_acpi USBC000:00: unknown error 0
[ 1387.041740] ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-5)
Having the monitor powered by another source and then connecting it, it also works with the FW13.
Framework: you need to do better with connecting forum posts to support tickets!
Received 7 hours ago:
Hi Adam,
We greatly apologize for the delay in response to you about this.
I have followed up with one of our engineers and we have been able to reproduce this issue and are working with our PD vendor on a fix for this.
This will not be in our next bios release, but we hope to have the fix in 2 releases from now.
If you have any further questions or concerns, please let us know as we are always happy to help however we can. Have a wonderful day!!!
Kind Regards
Framework Support
5 Likes
Thanks for contacting with the customer support and they finally forwarded the issue to the engineers to look into.
I did the same and they gave me a reply suggesting it being an issue on the iPhone side (since it only happened with an iPhone), while I demonstrated this being an issue of PD controller crash (affecting the other device on the same PD controller) which should not happen in any case.
I can understand their customer/technical support is barely capable of handling their userbase, and I am relieved to see this issue is on their todo list.
2 Likes
Probably offtopic for this thread but this is a choice Framework is making - they could absolutely train their support staff to be able to handle more complex issues, if not directly then knowing how to gather enough information and forward over to technicians.
4 Likes
I hesitate to write these words here but
I believe this also impacts a USB4 (Thunderbolt?) networking connection between an M3 Macbook and the Framework.
@voltagex
It’s really difficult supporting laptop users and any usb problem. For example, if some usb device does not work, it could be
- a bug in the usb device (not fixable by FW)
- a bug in a usb-pd chip. (The chips don’t output any debug logs)
- a bug in the EC code.
- a bug in the Linux kernel
It is unreasonable to expect one person to have detailed knowledge in all those areas so any support request is difficult to handle until it has passed across all the different experts.
For example, I doubt FW write the firmware for the usb pd chips, so anything related to them is likely to take a while to fix and timescales not necessarily in FW control.
1 Like
Sure, but that’s not what we’re talking about here
Sure, but if that was the case I’d expect that there needs to be a workaround or a recall and the PD chip vendor would be on the hook here. There’s also no technical reason you couldn’t have debug output at this level either.
What we’ve identified here, yes (I hope)
Sure, but in this thread in particular we very quickly worked out that if these problems happened even during POST and while in the UEFI UI, that it’s not OS specfic.
I don’t think I’m being unreasonable here. I do note that apparently I’m not using the best support channel (email), although I’m not sure why as I’m sure all the tickets end up in the same system.
1 Like
@voltagex
The post by @mwei above seems to point to the problem being with the USB-PD chip, and not the EC.
Debugging USB-PD firmware is hard due to lack of debug logs from them.
When problems happen with the USB-PD chip, the most I see is a line in the EC debug logs saying “… resetting…” the chip, without any reason why it needed resetting other than it probably being unresponsive.
The exact reset message from the ec console debug is:
CCG_RESPONSE_HARD_RESET_SENT
So, in summary, if the problem is in the USB-PD chip firmware, its going to really hard to diagnose and fix it.
4 Likes
I definitely appreciate this. Thanks for the explanation.
True, and it is wise to ask chip vendor for help on this.
and as this is 100% reproducible I don’t think it is too difficult to fix if you have right equipment (PD protocol analyzer, SWDIO etc) and setup. The datasheet for CCG8 suggests that they have SWDIO pinouts for debugging firmware in the PD controller:
1 Like
Today’s email update
We apologize for the delay in getting back to you as I followed up with some of our Engineers about this further. They shared with me that this is still an issue they are working on, but unfortunately do not have any other updates at the moment to share relating to this. We are sorry for the inconvenience this causes.
6 Likes