Open blackketter opened 1 year ago
I can reproduce the issue
Would be great to know what is causing this; by any chance do either of you have access to a usb pd sniffer? Alternatively does Mac OS log why it power reset the port?
Mac m1, reproduced. Needs use a usb 3.1 cable, with low-speed via hub works good.
IronOS 2.21.
Attached is a log of a couple of reboot cycles from Console.app, filtered on "usb": pincil_reboot_log.txt
I see a line
default 18:16:25.373241-0700 kernel usb-drd0-port-ss@00200000: AppleUSB40XHCITypeCPort::cableChangeOccurred: cable disconnected, powering off
but am unsure what the lines leading up to that mean...
I can report the same on my Linux laptop when connected to my TB3 port. Built 5d96470e4542f087ec0af76b31b586e7f49ff270 myself, not that it seems relevant in this case. I could potentially try to bisect if it would help.
This has just happened to me, using PineFlash on MacOS Ventura 13.3.1a.
Holding down + before inserting the USB-C cable shows some debug info when it's connected. When plugged in to a Pine Desktop supply (so 60W PD), it steps:
State 3 State 11 State 12 no vbus
and stays online. When connected to my iMac Thunderbird/USB-C port, it steps as follows:
State 3 State 12 State 11 no vbus (restarts)
The Mac console has:
error 18:18:40.165891+0100 kernel AppleIntelUSBXHCICommandRing: AppleUSBXHCICommandRing::setAddress: completed with result code 4
error 18:18:40.165960+0100 kernel AppleIntelUSBXHCICommandRing: AppleUSBXHCICommandRing::executeCommand: command[184] 0x0000000000000000 00000000 2c013c01 got result 0x0000000000311b80 0b000000 2c008400 after 0ms (enqueued 0ms)
error 18:18:40.165963+0100 kernel AppleIntelUSBXHCICommandRing: AppleUSBXHCICommandRing::stopEndpoint: completed with result code 11
default 18:18:40.166102+0100 kernel HS05@14200000: AppleUSBHostPort::createDevice: failed to create device (0xe00002bc)
error 18:18:42.139170+0100 kernel AppleIntelUSBXHCICommandRing: AppleUSBXHCICommandRing::executeCommand: command[187] 0x00000000004e3000 00000000 2d002c01 got result 0x0000000000311bb0 04000000 2d008400 after 0ms (enqueued 0ms)
error 18:18:42.139197+0100 kernel AppleIntelUSBXHCICommandRing: AppleUSBXHCICommandRing::setAddress: completed with result code 4
error 18:18:42.139283+0100 kernel AppleIntelUSBXHCICommandRing: AppleUSBXHCICommandRing::executeCommand: command[188] 0x0000000000000000 00000000 2d013c01 got result 0x0000000000311bc0 0b000000 2d008400 after 0ms (enqueued 0ms)
error 18:18:42.139290+0100 kernel AppleIntelUSBXHCICommandRing: AppleUSBXHCICommandRing::stopEndpoint: completed with result code 11
default 18:18:42.139430+0100 kernel HS05@14200000: AppleUSBHostPort::createDevice: failed to create device (0xe00002bc)
I'm working back through releases to find out what changed and where!
Would absolutely love a bisection to see what borked it. Even a quick and dirty check after every N PR merges would be amazing if you can. No pressure of course :)
USB failing to execute / act is expected (as we don't run a USB stack). I wouldn't expect that to cause the device to crash though.
Would be great if you could turn off the power pules in advanced settings and try again juust in case its that.
Would be great if you could turn off the power pules in advanced settings and try again juust in case its that.
I did, and it didn't help. Neither does enabling or disabling PDVpdo. Haven't had time to fully explore a bisect yet (up to my elbows in writing a plugin for SpamAssassin at work) but it'd help if someone could provide a me .bin file that doesn't have the problem, which might be easier than starting with
git bisect good <first commit>; git bisect bad <last commit>
๐
Welp... I went to bisect and found this issue occurring all the way back on 1fbcdcdf987a28541524e4f23ddc60fc942633ea, so bisecting to the source of the problem is out. Of note, it doesn't crash immediately after flashing the firmware, only after replugging the device. Right after flashing it boots and works fine.
Oh. I plugged my pinecil in (PD65W) yesterday because I was building an ADS-B antenna and had forgotten it wouldn't boot.
It booted cleanly. I haven't changed anything nor tried to flash it since last Friday. Doncha just love non-deterministic behaviour?
@blackketter Is this related to #1661? If so, please consider closing this to avoid duplicates. ๐ Or has that already been solved for you?
No, it's not related. This seems to be a separate issue that keeps happening regardless of wether BLE is on or off
Not sure if related, but I experience the same on my TS101 original FW 2.0 when connected to Macbook pro. Just keeps rebooting....
Same issue here, with a brand new just-arrived Pinecil V2 running v2.20.14DAF70 (13-12-22). I cannot update the firmware due to the rebooting issue as I only have access to a Macbook Air at the moment. What would happen if I powered the iron via the DC barrel plug (maybe at ~5V or some even lower voltage) and then connected it to USB? Would that allow it to connect successfully?
Same issue here, with a brand new just-arrived Pinecil V2 running v2.20.14DAF70 (13-12-22). I cannot update the firmware due to the rebooting issue as I only have access to a Macbook Air at the moment. What would happen if I powered the iron via the DC barrel plug (maybe at ~5V or some even lower voltage) and then connected it to USB? Would that allow it to connect successfully?
You shouldn't need to; updates work fine. Hold down the minus button and then plug the device in. It should work fine. The Iron only restarts when booting into the main OS and trying to request PD data.
Never connect both barrel jack and USB at the same time. The documentation warns you that doing so can damage your device.
@aguilaair Thanks! That worked, and I got my Pinecil updated to the latest version. @Sanaki Right, I did read that. I assumed it was a general warning for high-current DC supplies and hoped there might be some way of using the DC jack as auxiliary 5v power (current-limited using a bench power supply), allowing the iron to disregard whatever is going on with PD negotiation entirely.
@blackketter Is this issue still present? If not please don't forget to close. ๐
Updated to Release 2.22 - Release Candidate 2 and the issue still exist. Plugging into a USB hub or charger works fine, plugging directly into a MacBook Air M2 USB-C port directly causes a continuous reboot.
Plugging in to USB-C port on MacBook with a USB-C to A adapter then a USB-A to C cable works ok (though it's undervoltage at 5.1v)
I have the same issue just plugging in a PD sniffer into my MBP without the Pinecil attached so it could be an issue on that side
USB C to C directly to my Steam Deck or Ally both power cycled even in flashing mode on the factory firmware.
Haven't had the need yet to test on 2.22 but assuming it's the same.
Looks un-relevant on the first glance, but I've just got things strange. Sorry for the long story, but I want to describe all the nuances.
Yesterday I've got my new Pinecil V2 (moved from my old TS100 in case of USB-C powering). Just from the box Pinecil powerโoff itself at a random time from a standby mode simply when I'm browsing the settings. Trying to fix this I've decided to update firmware, and it's actually solved the described problem, but after this I've generated a new .dfu version of my custom boot logo and flash it using blisp (sudo ./blisp write -c bl70x --reset mylogo.png.dfu). This is where things become strange.
1) When you flash a logo, the -reset flag of blisp reboots a Pinecil and after that iron starts fine on 5V USB port of my mac. But if I reconnect it, it falls to the infinite boot loop, as described in this thread. Re-flashing main firmware do not help, because this process do not remove the custom logo. Also I've tried different logos: generated by myself, some pre-mades from this repo: https://github.com/Ralim/IronOS-Meta, even tried erase_stored_image.dfu, but the Pencil is never start up from my mac from now on as it was before, no matter what I'm trying to do. So, I think the problem is connected to existing a boot logo somehow?..
2) Also, after I flashed a custom logo, the Pinecil do not boot at all (just a black screen) from my UGreen 100W power brick, that I've used w/o any problems before. My other brick from Satechi with a similar power output still works well, so I'm confused.
When you flash a logo, the -reset flag of blisp reboots a Pinecil and after that iron starts fine on 5V USB port of my mac.
This will be because your connecting the unit in bootloader mode first, which doesnt do any PD negoitation so the laptop times out into "dumb" 5V mode. It isn't related to the logo itself. If you put it into bootloader mode, leave it for a minute or two and then use blisp to reboot it without replugging it will behave the same.
When in flashing mode (screen blank) there is no software running on the device to do the PD negotiation, so it just requests 5V via the default pull-down resistors in the PD IC.
The cycle looping is the PD not negotiating with the laptop (i.e. device and laptop are not coming to an agreement on the power profile). I'm not sure why and I would need a USB-PD capture of the negotiation to know why. I do not have access to Apple hardware to capture this.
Also, after I flashed a custom logo, the Pinecil do not boot at all (just a black screen) from my UGreen 100W power brick, that I've used w/o any problems before. My other brick from Satechi with a similar power output still works well, so I'm confused.
This should be unrelated, a boot logo should not break boot. Its best this is kept in its own issue.
This will be because your connecting the unit in bootloader mode first, which doesnt do any PD negoitation so the laptop times out into "dumb" 5V mode.
Yes, I understand this. Maybe it's hard to pin-point the main thing from my wall of text (sorry for that), but the thing is, that before there was a logo on my device (factory clean), the Pinecil boots well on the same port, on the same mac, with the same cable, but after I flashed a logo โ the issue described in this thread appears. I understand that it sounds absurd and like the problem SHOULD be un-relevant, but I just describe things as they happened. And also at the same time the behaviour of working with the power brick changed, so maybe there is something happened with the power management at the end. Maybe there IS a connection. As a developer you never know for sure.
After updating to 2.21.5d96470 with MacBook Air M2 with a USB-C cable directly connected between the devices, the Pinecil boots briefly, shows a 5.1v level, then crashes and reboots continuously.
This appears to be a PD issue, as the Pinecil won't crash if connected to a5v USB-A power source with a USB-A to USB-C cable. Plugging into an 18v coax or 60w USB-C port, the device functions normally (after disabling bluetooth per #1661).
I can still put the device into the boot loader and refresh while connected to the Mac, but the expected behavior is that the device stays up with status and menus working (albeit with a DC low warning).
version 2.21.5d96470