Pinecil clone "ej-sil" with N-MOSFET and gate driver

[EsaJaatinen]

Hi

I have a TS101 and so far I've been happy with it. I came across some posts that it can get overheated and checking the Pinecil schematics, the power stage could have much less losses. I'm here assuming that TS101 is a derivative from Pinecil.

I also wanted to challenge myself from the design point of view, how much electronics its possible to put inside a small device.

Some details:

• SEPIC to get 10V gate drive voltage
• 4mR MOSFETs to drive the tip
• 5V from a buck regulator
• 3.3V from a LDO
• 0.8 x 10 x 90 mm PCB
• Only USB-C, no DC
• Enclosure as 3d printed from JLCPCB

I have designed the device with STM32C071G8U6 as the mcu, but this is not available at JLCPCB so I'm now turning to the community as I want this to be as completely assembled as possible.

What (max) 4x4 mm microcontroller would you suggest from LCSC/JLC?

This will be 100% open source. Designed with KiCAD and Fusion 360.

Price estimate now is 61€ when ordered in batches of 5, and 46€ in batches of 10 (not including JLCPCB shipping). Some parts are from Digikey and OLED, screws, etc. from Aliexpress.

Also, the TS101 reboots occasionally with IronOS and original FW when operated with PD3.1 at 28V, and I tried to fix that also to the design. I suspect this is because the 5.1k pull-down resistors in the CC pins are GPIO controlled (from pinecil schematics) and some chargers might not supply any voltage without those. I haven't dug into the code and I'm assuming here a lot. If the firmware toggles them during operation, the charger might act funnily. My two cents about this issue.

And to show some flesh around the bones:

Kind regards, ej

[Ralim]

I suspect this is because the 5.1k pull-down resistors in the CC pins are GPIO controlled (from pinecil schematics) and some chargers might not supply any voltage without those.

These are controlled inside the FUSB chip as it has internal constant-current sink drivers that are used to provide the pull-down when required. The ones in the Pinecil schematic are DNP, they were designed in, only in-case someone wanted to create a software only PD stack (aka not using the FUSB).

STM32C071G8U6

I would not use this chip as its a fairly slow core and doesn't have much flash 😁 It meets the minimum but doesn't exceed further than that really.

[EsaJaatinen]

I suspect this is because the 5.1k pull-down resistors in the CC pins are GPIO controlled (from pinecil schematics) and some chargers might not supply any voltage without those.

These are controlled inside the FUSB chip as it has internal constant-current sink drivers that are used to provide the pull-down when required. The ones in the Pinecil schematic are DNP, they were designed in, only in-case someone wanted to create a software only PD stack (aka not using the FUSB).

A-ha! I hadn't delved into the datasheet yet.

STM32C071G8U6

I would not use this chip as its a fairly slow core and doesn't have much flash 😁 It meets the minimum but doesn't exceed further than that really.

What chip would you use?

I don't want/need any extra features to the soldering iron, just to be a good soldering iron. And to keep the costs to minimum, I started with minimum requirements :).

And regarding the cost estimate, it includes Finnish VAT (25.5%), so VAT0 prices are close to 49€ and 37€.

Kind regards, ej

[Ralim]

What chip would you use?

Depends how much software work you want to do really.

If you want the minimum software changes, use an STM32F1 series part with at least 128K of flash. Then flash IronOS-DFU to it. This will get you close to a TS101.

Otherwise I would use a F4/L4 part most likely. But really its best that you use a chip you are familiar with such that the software is easy enough.

[EsaJaatinen]

Thanks for the tips!

[Ralim]

I think your response was deleted or went missing? (I got the email).

Firmware support should be doable, though without a unit its hard to do too much. If you have some past experience programming the STM32 porting shouldn't be super hard. (I'm happy to help).

If possible can you make schematics available before you order samples for me to skim just to see if you do anything to make porting hard 😁

[EsaJaatinen]

Firmware support should be doable, though without a unit its hard to do too much. If you have some past experience programming the STM32 porting shouldn't be super hard. (I'm happy to help).

I got the FW somewhat forward, but when STM32cubeIDE started to nag about c++ classes used in .c files my learning curve started to skyrocket.

...and the next day I found my issue.

Kind regards, ej

[EsaJaatinen]

I have got some errors fixed, but I keep hitting mixed C and Cpp issues. I don't think I should need to do this kind of edits (wrap the C headers) to the source to get it compiling:

extern "C" {
#include "FreeRTOS.h"
#include "OperatingModeUtilities.h"
#include "task.h"
}

Most likely this is due to my lack of experience in programming, but it still doesn't feel right.

All help is much appreciated. 😄

Kind regards, Esa

[Ralim]

Hello, as I dont use any devices with STM32's these days I dont have STM32CubeIDE installed anymore.
It was removed a long time ago as it got too painful to keep updating the project files to handle changes (and the whole Atollic->STMCube change).

You should not require those edits if its using the correct compiler setup for C/C++ with the include paths setup. I.e. it should only use gcc for .c and g++ for .cpp. Its quite possible some of these have slipped through given the code will always be compiled in the same order normally (and STMCube may do it differently). Most of the c++ headers have extern "C" guards already 😢

Sadly I don't have a good means to provide support for STMCube software these days, I use Zed/Codium for all editing.

[EsaJaatinen]

My ADHD (not official but visible enough :) kicked in and I asked some stupid stuff that I figured out myself the next day 😆.

A flu hit me so I don't have the energy to publish all files right now, but here's the most important parts through copy-paste.

LCSC has STM32L432KBU6TR available so I swithced to that following your suggestion. STM32cubeMX is ok with the pinout, HW PWM, USB clock through the automatic trimming (crystal less), 80MHz internal clock ok. However, I can't 100% rule out brainfarts as my programming is practically limited to Arduino IDE (AVR and stm32duino).

mcu part of the schematics:

Pinout:

My colleagues at work have more software experience and I have already recuited them to this project to some extent. As soon as I get well I'll try to get the FW side forward, but should I hit a wall I'll ask you for help. Thanks in advance!

Kind regards, ej

[EsaJaatinen]

Here's a zip for kicad files. I'd really appreciate all feedback.

ej-sil 1r2 - L4.zip

[Ralim]

This seems sane to me.

I would maybe expose UART or SWD instead of the I2C on the USB-C. (Personal choice though).

I haven't validated any of the mosfet driving side; but I dont see any big reason why it wont work. Noting that generally we dont want a perfectly sharp mosfet turn on, and its ideal if it takes a tiny bit of time (even though it means mosfet heat) as this improves PSU compatibility. If the turn on is too sharp USB-C supplies can latch off or go bang 😓. This design should be easy to tweak for that if the need arises though.

Maybe the pads for the tip contacts could expose more area for the little clamp things to touch.

I don't see anything that would stop a prototype at a look.

[EsaJaatinen]

How possible (= work hours) would it be to change the FW so that when the tip heating is turned on, the PWM pulse generator would make a "ramp up"? I.e. generating increasing amount of PWM pulses in order to draw an increasing current from the PSU? And a "ramp down" when turning the heating off. I'm assuming the capacitance at the PCB and at the PSU would be enough for this. With fast MOSTFET switching (and related gate driving circuit) this would be possible MOSFET power dissipation wise and would increase the PSU compatibility.

Also, if the AC coupling capacitor is replaced with low value resistor, the heating could be driven with "real PWM" instead of pulses. I do like the safety feature though.

I ordered first batch of prototypes with slow-ish MOSFET switching (higher gate resistor value), but I might return to this idea later on.

[Ralim]

so that when the tip heating is turned on, the PWM pulse generator would make a "ramp up"? I.e. generating increasing amount of PWM pulses in order to draw an increasing current from the PSU?

This doesn't particularly play well with the AC coupling capacity. As the firmware aims to drive this at a fairly constant drive to ensure we ramp up and on the mosfet drive signal.

The main tip "PWM" is like 5-10Hz, its slow because the 2 contact style tips cant have their temperature measured and PWM driven at same time, so we need off periods to measure. Which means the more we measure, the less we can drive the tip (as measurement is a constant forced off time).

Also, if the AC coupling capacitor is replaced with low value resistor, the heating could be driven with "real PWM" instead of pulses. I do like the safety feature though.

If this is done instead, then yeah you dont need any of this and the power will ramp up and down based on the PID control