All About USB-C: Pinecil Soldering Iron

As many people have pointed out, what matters with USB-C isn’t just the standard, it’s the implementations. After all, it’s the implementations that we actually have to deal with, and it’s where most of the problems with USB-C arise. There is some fault to the standard, like lack of cable markings from the get-go, but at this point, I’m convinced that the USB-C standard is a lot better than some people think.

I’d like to walk you through a few USB-C implementations in real, open-source, adjacent, and just interesting products. They’re all imperfect in some way – it can’t be otherwise, as they have to deal with the messy real world, where perfection is a rarity.

Today, let’s check out the Pinecil. A soldering iron by Pine64, released a few years ago, keeping the price low and quality high. It sports both a barrel jack and a USB-C port for its power input – a welcome departure from the Miniware iron strategy, where neither the barrel-jack-only TS100 nor the low-power proprietary-tip TS80 irons quite did it. And, given its design around TS100 T12-style tips, it’s no wonder Pinecil took a well-deserved spot in hobbyist world.

Can’t Just Pull The Trigger

Now, you might be thinking that Pinecil ought to be a simple device. The usual way to get high power out of a USB-C port is a Power Delivery (PD) trigger IC, and you could merely use that. However, if you’ve read the USB-C power article, you might remember the 45 W vs 60 W charger scenario, where such an arrangement would fail immediately. Overall, the configurability of trigger ICs is quite low, and when encountering a PD compatibility problem with some PSU, you can’t do anything about it except replace the IC with a slightly-different-logic IC- if a replacement even exists, and it usually does not. This is costly and limiting for a real-world use product.

Pinecil went the “PD stack software + PD frontend IC” way, devoting part of the MCU to the realtime nature of PD communications. The PD frontend used is the FUSB302, connected to the MCU over the regular I2C interface. The microcontroller itself has changed from the GD32VF103 in Pinecil v1 to the BL706 in Pinecil v2 – both of them RISC-V.

Now, I’ve started talking in abstract here, but it makes sense to talk about the hacker doing the actual work at making the PD stack possible – in fact, the entire Pinecil software stack. The person responsible for the PD and overall Pinecil software is [Ralim], known for his IronOS firmware initially developed for TS100, TS80 and other soldering irons with MCUs on them. Pine64 reached out to [Ralim] back when Pinecil was just a concept, asking if he’d be available to port IronOS, including the required PD work.

Over the years, the “frontend + MCU” approach has paid off tremendously. A major reason is PSU compatibility – there’s a ton of variance within USB-C power supply communications out there, as the PD stuff can be hard to implement, especially when it comes to edgecases. The initial firmware on the Pinecil irons, indeed, didn’t work with a number of power supplies out there – including, for instance, some Apple power bricks.

Now, the beautiful thing is, whenever someone filed a PSU compatibility issue on GitHub, [Ralim] could track this issue down, either by remote ‘try this binary’ debugging, or by straight up buying the same PSU. Then, he would fix the issue by changing how the stack treats edge cases, test the fix, and upload a new Pinecil firmware version on GitHub for everyone to use. Within a year, most of the USB-C issues were gone, and if you have a Pinecil problem, it’s likely that you only need to update the firmware from the factory-flashed old version.

Over the years, the stack has become quite mature, and most importantly, battle-tested – it’s tricky to find a PSU that the Pinecil doesn’t work with nowadays. For debugging and hacker convenience reasons, if you plug a USB-C PSU into your Pinecil while holding the + button, you will be shown a PD debug menu listing all the profiles – in a way, the Pinecil is  a PD debugger tool that you might already own.

Would such an approach work for a small-scale hobbyist USB-C power supply-requiring project? Not back when the Pinecil was new, perhaps. However, today, the PD stack is open-source and mature.

Leading USB-C In Open-Source

Writing a USB-C PD software stack is not as straightforward as writing, say, an ADC driver. To enforce the coexistence and safety requirements, USB-C uses state machines. If you’ve ever had someone share one of these intimidating diagrams straight from USB-C documentation pages with you, you might be inclined to believe that USB-C is best not touched by humans. That viewpoint isn’t entirely wrong – reimplementing these state machines is not something you necessarily might want to spend your time doing. On the other hand, despite the informationally aggressive nature, the state machines involved are simpler than they might look.

That said, if you’re dreaming of a USB-C-talking open-source project, you don’t want to start from scratch, and you don’t have to. Nowadays, thanks to [Ralim]’s work, we have an open-source PD stack at our fingertips. It’s in C++, and is designed to work with an RTOS – as USB-C requires reasonably fast responses to parts of the protocol, enforced on the power supply side. This stack was started by [Clara Hobbs] as part of the PD Buddy Sink project, and grew into an actual library you want to use if you, too, look to develop your own USB-C-powered device.

The stack is well-tested, thanks to a notable collection of various USB-C PSUs that Ralim owns and can test with – perhaps, this is what makes this stack the most valuable. However, it also serves as a USB-C playground. When EPR chargers, like the Apple’s 140 W one, started appearing on the market, they had 28 V available – something that the Pinecil could use to jump from 50 W to 98 W of tip heating power. In a few months’ time, the SPR-only stack gained EPR compatibility and we saw first Pinecils getting 28 V power from Apple chargers, making it the first open-source project able to deal with the additional requirements of EPR.

Frontend Variance Woes

The PD frontend IC used, FUSB302, has a bizarre aspect to it – its datasheet specifies two maximum voltages on its VBUS pin, 21 V “recommended maximum” and 28 V “absolute maximum”. Now, this pin was connected to the VBUS power trace on the USB-C port, which is to say, to the power input. Early on, this caused community concerns, and while someone did test 24 V compatibility and post convincing curve tracer graphs, the Pinecil was label-downgraded by stating that it’d only be compatible with 21 V or lower supplies – excluding 24 V supplies, a disadvantage over the TS100.

Later on, it might’ve happened that the FUSB302 became more sensitive due to manufacturing tolerances in different batches. I happened to hang out and do volunteer tech support in Pine64’s Pinecil chat, and what we met back then was a trend – someone used a cheap barrel jack power supply, or accidentally plugged a 24 V supply in, or just used a regular 20 V USB-C brick, and the FUSB302 would die. Sometimes it would die quietly and make the iron only work through barrel jack or QC; sometimes the FUSB302 would short the internal 3.3 V rail and bring the entire iron down permanently, requiring hot air removal to revive the Pinecil.

The issues weren’t prominent when keeping the total amount of Pinecils sold in perspective, but they were definitely a trend, and we were curious. At some point, [Thanos the tank engine], a fellow hacker, decided to dig into it and figure out what the fix could be. Together with [Ralim], they figured out that the VBUS pin connection was not used in software at all, and in fact, could be completely disconnected. What followed was the “VBUS mod” – a hack would add 24 V support to the Pinecil by removing the VBUS connection, with video instructions on how to properly cut the trace involved.

[Ralim] modified the firmware to detect whether the mod has been performed correctly, as a failsafe for users who might’ve missed a sliver of copper the first time. The fix eventually made it into a new Pinecil PCB revision, too, and the Pinecil V2. Overall, it’s a wonderful short story of how large open-source products with a thriving community turn into a force multiplier.

Non-Compliance For Compatibility And Debugging

USB-C is designed to get rid of proprietary charging standards, and this is why the USB-C standard says that you shall not support USB-data-pair-hijacking charger communication standards like QC on your USB-C ports. The goal of the Pinecil is to be accessible, however, and this part of the USB-C specification had to be ignored. So, apart from PD support, there’s also QC support in case a QC charger or powerbank is what you have to work with – hacker accessibility matters more than USB-C compliance. It’s not the only part of USB-C standard that the Pinecil violates for good reasons, either.

The high-speed and SBU signals on the Pinecil’s USB-C port are used for a variety of signals – JTAG, SPI, I2C, UART and a few ADCs from the main MCU. As a result, the Pinecil is a RISC-V and USB-PD devboard, with a cheap breakout board to match. Not a lot of people have taken advantage of these signals, but they’re definitely available, and initially, they were used during the Pinecil development – so why leave them out on the production version?

The USB-C specification does allow reuse of these signals for debug purposes, but it does require a multiplexer to shut them off until the debug mode is summoned; hence, the Pinecil is not compliant in that regard. On the other hand, there would’ve been no space on the Pinecil PCB for a multiplexer, and it would’ve caused too much of a price increase for a rarely used feature that’s still good enough to not pass up on. Instead, just in case someone used a high-speed cable to connect a Pinecil to a USB3 port, the signals were arranged in a way that none of the set-as-output GPIOs were connected to the TX pair of the USB3 – and no users ever raised any issues. Even if they did, using a different cable would suffice, and if the issues were to turn out to be frequent, there were 0 R jumpers that could be omitted at the factory; thankfully, none of that was required.

Non-Compliance Out Of Need, With Spicy Consequences

When reading the FUSB302 story, you might have asked – how could it be that barrel jack voltage could get to the FUSB302’s VBUS? The reason is simple – the barrel jack center pin and USB-C VBUS are connected together. If you ever design a product with dual power inputs, this is what you must never do. However, it seems, Pine64 had no other way but to do just that. Instead, they selected the barrel jack and the USB-C port with lowest possible mechanical profiles, making it impossible to insert cables into both of these sockets at the same time – creating a mechanical interlock of sorts.

Now, there’s no reason you’d ever plug both of these connectors in at the same time, unless you’re using the Pinecil as a fancy trigger board – which you theoretically could, if it weren’t for the mechanical impossibility. There aren’t any instructions that ask you to do this, either. That said, there are two stories of someone deciding to insert both a barrel jack and a USB-C cable while they were trying to flash firmware, burning the computers they were using for that. This was a puzzling occurrence – nobody in the Pinecil community could fit both plugs in at the same time, even though we sure tried.

Ultimately, this was a design tradeoff, where a mechanical route was taken to solving a possible problem – and it was a successful solution. You gotta have a very specific set of circumstances to even get to a place where a failure mode is possible, and at this point, the failure rate approaches the same percentage you’d get if Pine64 were to put a FET switch or a diode in the way of the USB-C port; power switching components like to fail short-circuit, after all. On the community side, we did figure out a further fix, however – updating all flashing instructions and the custom Pinecil flasher tool, warning the user that they have to remove the barrel jack PSU before flashing. After the warnings have been added, this issue has been unheard of.

Nets A Good Outcome

There’s considerable might behind an open-source project that’s been manufactured in tens of thousands of units and got into hands of hobbyists and hackers across the globe. My Pinecil has never let me down, and its USB-C capabilities is something I ended up relying upon. We shouldn’t undervalue the gift that is a battle-tested open-source PD stack, either. While the USB-C implementation of the Pinecil isn’t flawless, it’s been a large benefit to hackers all over the world; and there’s a trove of stories to learn from, too.

from Blog – Hackaday https://ift.tt/3VUZaEO