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.
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.
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.
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.
@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.
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:
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.
Whose fault this is aside; this really is unfortunate. I am a new Framework user and definitely wasn’t expecting such oddity as this. It seems on one side of the fence or the other something would’ve happened with this by now
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.
I don’t think so either. I should be able to charge my phone with the computer plugged in and the lid closed (sleeping), which means the Linux kernel isn’t involved, which makes it a weird USB C PD issue.
And the fact that it works literally everywhere but on my Framework makes it a Framework problem. At least, they should be extremely interested and point elsewhere if they somehow determine that theirs is the one device in the known universe that has uncovered some bizarre bug in Apple devices.
That said, I’m willing to give Framework a pass if they say, “Look we know it. We’ve got it queued up. And we’d get it done tomorrow if we had the resources and/or you were willing to spend $5k on our hardware.” It’s a small company, and as odd and disappointing as this problem is, they get a break. I like them and I like their policies and honesty.
Just to add my name to the screaming void, I too am super frustrated by this issue. It seems to me to be related to any USB-C device that can both accept and provide power. If I plug in my portable external monitor (which is not connected to a power source), I can actually see the laptop battery charge indicator (in windows) cycle on and off repeatedly as it tries to figure out what to do. This is the same thing that happens with an iPhone or iPad. These devices work with every other computer that I have. The framework 16 is the only one that has the problem.
I just tested this on my Pixel 4a and I cannot reproduce the issue at all. Are you guys using USB-C cables that can send data? Some cables are designed to only pass power and could cause compatibility issues.
Yes, I have tried several different, known good cables. I have spent hours trying to get various devices to work. I’m also a well seasoned IT pro so I’m pretty thorough before I start complaining publicly.
I’ve tried full and less than full, on AC and not on AC. And to be clear, it’s not just the iPhone. It’s several devices. The external monitor being the most frustrating. That monitor works just fine on a recent Dell, a Surface Pro, my Desktop PC, my iPad, really anything that supports DisplayPort over USB-C, except my FW16.
