Pinecil boot-looping on v2.16 when connected to computer USB (low power)

[ajorg]

I upgraded to v2.16 last night and while the Pinecil is stable when connected to a PD power supply it boot-loops when connected to my computer, which does not supply high power. It worked fine on v2.15 and below.

[Ralim]

What computer are you connecting it to, how are you connecting it (what cable type)?
Did you test any of the RC releases or just the latest final tag?

[ajorg]

What computer are you connecting it to

Samsung Galaxy Chromebook (v1)

Today I tested on several other computers and it does work on some of them.

boot-loops

ASUS Chromebook Tab 10
Google Pixel Slate
Lenovo 300e Chromebook (2nd Gen)

works

Lenovo N23 Yoga Chromebook
Lenovo ideapad 130S-11IGM (running Linux 5.4)
ThinkCentre M90n IoT (running Windows 11)
Pixel 5a (Android 12)

It's tempting to think that the problem is Chromebook-specific, but given that one Chromebook worked I'm tempted to either rule that out or suspect that it's a specific kernel version that's being a bit pickier about USB negotiation.

how are you connecting it (what cable type)?

USB-C to USB-C that came with an 18W power supply.

I also tried putting a Satechi USB-C Power Meter inline with it, and in the cases where it works it shows a voltage (usually 5V) and very little current, but in the cases where it doesn't work it shows nothing at all. This suggests that part of the initial negotiation may be failing, but I can't be sure. The Satechi meter snoops the negotiation packets but doesn't interfere.

Did you test any of the RC releases or just the latest final tag?

I had only tested v2.16 (broken) and v2.15 (works).

Having tested the RCs now...
RC1 shows a corrupted display (looks like static) but doesn't boot-loop.
RC2 boot-loops. Display looks different than on v2.16 but doesn't look like static.

Another detail I should have added is that the bootloader works correctly on the Galaxy Chromebook, and the Satechi meter reads 5V and 0.01A when the Pinecil is in bootloader.

Let me know if there's anything else I should try.

[ajorg]

It also works when using a USB-A to USB-C cable attached to a USB-C to USB-A adapter so that it doesn't try to negotiate USB-C.

[ajorg]

Possibly useful, but more likely a symptom of the boot-looping, dmesg on the Chromebook shows the following repeatedly (with variations on time and device number):

<6>[96276.137719] usb 1-2: new full-speed USB device number 43 using xhci_hcd
<3>[96276.251742] usb 1-2: device descriptor read/64, error -71
<3>[96276.473739] usb 1-2: device descriptor read/64, error -71

That's with Linux 4.19.208-12427-gf85a69d601ba x86_64.

[Ralim]

Ah fantastic you answered all my follow-up questions too.

So what I suspect is going on here is a stalemate in negotiations. The pinecil will NACK any requests for it to change data or power modes.

This is probably down to the exact PD stack in use on the devices.

Is there anyway to spy on the PD stack in these devices ?

[ajorg]

Is there anyway to spy on the PD stack in these devices ?

Not that I know of, but I'll poke around and see if I can learn something.

[Ralim]

<3>[96276.473739] usb 1-2: device descriptor read/64, error -71
This is because we dont implement any USB during runtime.

Does make me wonder if its trying to power cycle the port to get the unit to talk to it.. :/ (Is that in the logs?)

[ajorg]

Does make me wonder if its trying to power cycle the port to get the unit to talk to it.. :/ (Is that in the logs?)

Ah, yep:

<6>[96274.695793] usb usb1-port2: attempt power cycle

[Ralim]

I'm suspect this may be either PD fighting or the usb port power cycling ; as the computer is seeing the QC activity and thinking we are a non-functional USB device.

[ajorg]

I wonder if it should present as a HID temperature sensor, since temperature's a thing it knows about itself. Not sure it would be very useful, but might at least satisfy picky computers that reset USB devices that don't respond.

What was it doing differently in v2.15 in this regard?

[VaZso]

I have simply overlooked it but I have realized it when I saw this issue just now...

So I have tested the actual IronOS image a few weeks ago to see if it works well for me.
...then I have only found a Type-C to Type-C cable when I wanted to update when 2.16 has appeared and my Pinecil did the same rebooting.

I have simply replaced the cable with a USB-->Type-C one and did the upgrade there.

So I have not dag into it at all, but my computer has a Type-C port which is not PD capable, so it will never switch to a voltage above 5V (it is a Thunderbolt-capable port without PD support).
Anyway, I have updated my Pinecil using the very same cable and very same OS earlier and QC pulses were already there not causing restart (even had PD timeout set to 15 because of my QC chargers).

I may look at it later what is really happening if you feel it should be investigated further (maybe this weekend).

[EricAndrechek]

@VaZso thank you for coming back to update on the USB issue! My Pinecil screen blacked out and it wouldn't heat up, so I installed PineFlash on MacOS and plugged in my Pinecil via a USB-C to USB-C cable straight to my Mac. The soldering iron would connect, but when I started the update it would error out with:

Failed to receive response, ret: 0
Failed to get boot info.

I could not find any other mentions of this problem on the internet and started looking through Github issues in desperation before seeing your comment here. I swapped my USB-C to USB-C cable out for a USB-A to USB-C cable plugged into a dongle on my Mac, and it worked first try! Thank you!