TS80P v2.13 keep rebooting when connected to my Apple MacBook Pro

[Airmonkdev]

This is a Bug

• I have

  • [X ] Searched previous issues
  • [X ] This is in this firmware, not vendor "offical" firmware
  • [ X] This is not a bug in the vendor bootloader (aka DFU)
  • [X ] I have checked this is not already covered in the docs in /Documentation

• What is the current behavior? Connecting the TS80P to my Apple MacBook Pro 13" 2020 USB-C port (Thunderbolt 3) it keep rebooting.

• What is the expected behavior? It should works fine.

Steps to reproduce the bug: Just connect the TS80P.

• What are you running: TS80P v2.13 build: https://github.com/Ralim/IronOS/actions/runs/460858679

On the idle screen, you can hold the settings button and it will show you the firmware & PCB version. If using a USB-C supply please note model number

• Firmware Version: 2.13 04-01-21
• PCB Version: 4
• Power Supply (Voltage and Current Rating) :Apple as described.

[vini-nu]

Power Supply (Voltage and Current Rating) :Apple as described.

C'mon don't be that lazy. As much as you, no one wants to do extra googling... Update the issue description with number values...

[Airmonkdev]

Sorry for that, I'm not that lazy, I really don't know that numbers! As I wrote I'm using the USB-C port of my MacBook, not the charger, and can't find that spec.

[vini-nu]

Probably only 5V 2-3A.

[MacDragon]

Yes, I suspect it's 5v 3A max, as I think they're rated for 15W output in theory.

[Ralim]

Hi @Airmonkdev If you have not yet already tried the later firmwares, could you please give the latest release a try?

[Airmonkdev]

Hi @Ralim , thanks for reply! I've just tried but yes it still keep rebooting also with the last release. :(

[Ralim]

Can you take a video of it power cycling so I can try and eyeball where the code is up to when it reboots?

[Airmonkdev]

Here there is the video: https://www.dropbox.com/s/mgghars8q8qk4zg/TS80P%20Apple%20MacBook%20Air%20M1.mp4?dl=0

The TS80P is connected to my Apple MacBook Air 13" 2020 with M1 CPU

[Ralim]

Thank you for the video. So the macbook is hard resetting the iron. As to why is anyone's guess really. Could be a quirk of apples implementation of USB-PD in their new silicon.

I'm working on more in depth testing of the PD stack, which may uncover something. But honestly, I have no idea why the MPB is sending out a hard reset.

Also, why are you powering the iron from the MBP in the first place? Its not really going to work on 5V 😁

[discip]

@Airmonkdev Is this solved for you, after updating to the latest release? If so, please consider closing this issue. 😊

thanks

[damex]

I have the same issue on MacBook Pro 13' 2020 and MacBook Pro 13' 2018. using different usb-c cables like 3a or 5a or usb2.0 or 3.0 (or higher) does not change anything.

IronOS boots up and get restarted/reset immediately after showing main screen for few ms. I run IronOS v2.18 and IronOS-DFU v0.2. it works fine on stock firmware and connecting in DFU mode on either stock boot loader or IronOS-DFU works fine too.

connecting to acer predator triton 500 se (10th gen) usb-c port works fine and connecting to dedicated charger (like stock Miniware comes with or Anker PD5 or Anker Atom PD4) works fine.

[dzarda]

This issue is caused by the FUSB302 not responding with a GoodCRC to incoming PD 3.0 messages not declared in PD 2.0. The datasheet declares support for only PD 2.0 and any PD 3.0 features (PPS, EPR) in this project (and others including mine) have been functioning due to sheer luck.

The MacBooks issue a Get_Source_Capabilities_Ext Control message during the handshaking. As this is a message not defined in 2.0 the FUSB302's auto-CRC mechanism doesn't respond with a GoodCRC. The MacBook tries the message 4 times followed by a Soft/Hard reset hell perpetrated by both sides. All USB-C capable MacBooks are AFAIK affected as this seems like FW/driver behavior independent of CPU HW - Intel/Mx all affected.

A mitigation I've come up with is to report PD 2.0 support in case the Source_Capabilities doesn't include PD 3.0 features we want to use (PPS in my case.) The MacBook exposes a simple 5V PDO so will fall in this 2.0 category. When we state in our communication that we only support 2.0 then the other side must not post 3.0 content. No 3.0 support -> no Get_Source_Capabilities_Ext -> no resetting on Macs' USB-C ports.

Our logic in pe_sink_wait_cap() is then:

bool sourceHasPps = false;
/* Does the source support PPS? */
for (int i = 0; i < PD_NUMOBJ_GET(&tempMessage); i++) {
  if ((tempMessage.obj[i] & PD_PDO_TYPE) == PD_PDO_TYPE_AUGMENTED &&
      (tempMessage.obj[i] & PD_APDO_TYPE) == PD_APDO_TYPE_PPS) {
    sourceHasPps = true;
    break;
  }
}

if ((tempMessage.hdr & PD_HDR_SPECREV) >= PD_SPECREV_3_0 && sourceHasPps) {
  hdr_template |= PD_SPECREV_3_0;
} else {
  hdr_template |= PD_SPECREV_2_0;
}

Nevertheless the lesson learned is: Don't use hardware certified for PD 2.0 (FUSB302) in PD 3.0 communication.

---

We can see that PD 3.0 extended the MsgType field in the Header by a fifth bit:

PD 3.0 adds new Control Message types. The FUSB302 apparently doesn't like this 1 in the header.

[Ralim]

Hello, thank you for digging into this, this puts us on a massive lead.

Are you able to share the PD captures you used for finding this?

We can work around this by sending the CRC from software; however I just want to check what timings look like etc, and having a computer failed negotiation capture can often help narrow down the issue very quickly.

I'm a bit surprised that this is occuring given that when tested here I think (old memories) that this was working fine on the Pinecil and TS101 when working with EPR and that I did spot check to the onsemi rep and they believed that there would be no issue in the hardware state machine.

Again, those are very old memories. But it is quite probable that it is a bug causing this, I'd love the captures so I can try and trace down any other potential causes first. (I don't have a machine to test this on).

Given the TS80P is one of the only devices with a limited setup for PD capabilities it's very probable it has a big somewhere I haven't caught. It also potentially has one of the smaller userbases out of the PD devices 😢.

Take with a grain of salt of course, please. I haven't looked at the PD stack in a while. Usually so far the blocker for these events has been inability to get packet captures to see what's going on.

Your point of not bothering with PD3.0 if we don't need to is also a very good one, I would be happy to look at a PR for the change, but I'll need to refresh my mind on the rest of the code paths for other devices. (Worst case, can mask it to the easy cases at least). Definitely feels like a bug we are requesting this on the TS80P as it should be masked from EPR code paths.

Could also be that that we do goodcrc but don't send back a response fast enough (probably because of a bad mask)

[dzarda]

Hi, from what I've encountered so far on our device (not a soldering iron) the GoodCRC is not being sent at all. I can share the TotalPhase data I have from our device from before and after the mitigation applied:

TotalPhase_Mac_captures.zip

I should have the captures from IronOS on TS80P available on thursday.

The idea about sending a GoodCRC from software in these cases also crossed my mind. You have a very tight window in order to accomplish it but it should be possible as you have four tries to make it on time.

[Ralim]

This should fix the EPR negotiation occurring. I haven't been able to replicate the non-working goodcrc here; the fusb302 is working fine at good-crc'ing EPR packets on the two EPR supplies I have here. Would be good to see captures if you have themto compare.