CFW for KSGER/Quicko STM32 Soldering Stations

[DavidAlfa]

Yes, I'm trying to use the HAL. But they should explain a lot of things.
In the end you mess your brain up searching on  internet and you don't find much either.
For the simple it works.
It's when you want to start connecting stuff, that pain happens.

Thanks for the link, looks interesting. https://visualgdb.com/tutorials/arm/stm32/adc/
I hope they use ADC Interleaved in DMA mode, otherwise I already know how to use the other modes.

And...! I think I confused Visual Studio with Visual Studio Code.
The first seems what they're using in that link, it looks very tidy! Was that Visual Studio what you were saying?

The second is an Arduino-like mess, everything must be set in JSON files, I don't understand that logic...
You must first master at JSON coding, then study how VSCode uses it.. and then, maybe, you can start programming!
Furthermore, after that you see how STM HAL works ... That day you'll be a step of getting into the drugs!
(For arduino I use Eclipse-based Sloeber IDE, keep the original ArBuguino away from me!)

What ST really lacks is Technical notes. Yes, the datasheet describes everything, but doesn't it make easy to understand.
If you ever saw the Microhip ones, they have the full datasheet, but appart of that, a whole book for each peripheral!

I've spent days just trying to domimate the timers and the ADC modes.
But I'm doing everything in my STM32F429 discovery (I got it in the  industrial revolution era, 2013 I think).
I remember when I bought it, I saw the libraries and... Spend a week on it! No way I'm trying to understand this anymore!
They used 4x more text just to init a GPIO, that was a inmense mess.
The technical documentation was, yes, way worse.
So I used it as a paperweight all this years!

I'd like to met with people who made Doom run on it... How did they learn?
Even knowing the Cortex architecture, the STM perpiherals are on its own, glued to the ARM core.

[dreamcat4]

And...! I think I confused Visual Studio with Visual Studio Code.
The first seems what they're using in that link, it looks very tidy! Was that Visual Studio what you were saying?

Yeah... I was referring to installing VSCode, then ontop of that also installing the "PlatformIO" Plugin for VSCode. This then allows you to install the ST libraries, or alternatively install one of several other systems. And be able to create new projects (or open existing ones). All they do is add an extra file names "platformio.ini". Which then is a config file to tell platformio which build system you want to use for a specific project.

Actually it gets messy in there. Because there are multiple different ways to do the same thing. At least when it comes to configuring your project. Especially for setting up things like openocd, for intercative debugging.

It also gets complicated because while platformio is a plugin of VSCode, it also has it's own plugins system. So you can install plugins for platformio itself too.

So you can get lost in there. However it does look to be 'the future'. So that you can try out other environments. For example like myself, for creating a new embedded project in rust. And of course you are not limited to ST hardware targets. But can instead create projects for other hardware architectures too. IF it works....

... it does not always work. Or not without extra tweaking etc. And the right extra 'magic'. Certain things seem to be broken in PlatformIO. And may be fixed 'at some point' in the future. Or by other users finding out how to configure things.

So just be aware of that going in. It's not really 'finished' yet. More of a moving target. Some things already work. Other things do not currently work because they require more work and 'polish'.

I've spent days just trying to domimate the timers and the ADC modes.
...
The technical documentation was, yes, way worse.

My approach to dealing with "the ST problem". We all know what it is.... the over complicated mess. My approach is to use google as the first line of enquiry. And refine search terms. Until I get to finding the frustrated blog post of somebody else who already got really frustrated by the problem and decided to write an article about it. Then I work backwards into the technical docs from there. To fill in any remaining details that were referenced in the article but not fully covered by it.

This approach seems to be the more time efficient way. Because it's simply not feasible to budget enough time to read through the ST docs. They are far too big! And also because the 'matrix' way they multiply x*y their product stack. Leading to multiple different docs everything spread around to find in different places. Or with * side-notes because the "high pin count version only" etc. It quickly becomes too much to keep in your all head at once.

[mikes]

OK. I just read the whole thread. I ordered a 2.1S (whatever that really means). Recent discussion is about the difficulty dealing with all the different hardware revs, different processors, etc., and STM development complexity. I go back to this:

And really the only platform i can actually think of which satisfies all of those requirements well right now (2020) is ESP32. It also has 2 cores so potentially can drive the display off a different core than thesoldering  tip.

Seems to me that using the basic physical platform, and making a new, replacement controller could focus development onto a unified architecture which is supported by an easier to use development platform (PlatformIO?, although I haven't had any real problems caused by Arduino IDE). If an ESP32-DEVKIT-C will fit (seems like it might - it's ~28 mm wide, the black case KSGER is about 38 mm on the outside, and it looks like there might be enough room to accommodate the board height), that seems a good fit - non-technical users could easily load firmware via USB with little difficulty.

ESP32 - dual core, 240 MHz, 520 K RAM, typically 4 M flash/code. STM32, 1/3 or less of all of that, and only a couple of dollars more for a devboard than a bare STM32 chip. The ADC sucks, so an external one would be needed, but the rest of the circuitry would be comparable. Could even use the WiFi for OTA upgrades or simple web based configuration, and make it the first(?) IOT soldering station.

The Unisolder is very capable, but overly complex.

I'm decent at hardware, a hack at programming (maybe ugly, but works). But I'd contribute however I can.

[DavidAlfa]

Yep, I've been having an eye at the ESP32 too for a long time. Plus its ridiculous low price!

Okay, I finally found the culprit.
In the datasheet:

Code: [Select]

In multi ADC mode, the start of conversion is triggered alternately or simultaneously by the
ADC1 master to the ADC2 and ADC3 slaves, depending on the mode selected by the
MULTI[4:0] bits in the ADC_CCR register.

Then at the Triple interleaved mode description:

Code: [Select]

If the conversion sequence is interrupted (for instance when DMA end of transfer occurs),
the multi-ADC sequencer must be reset by configuring it in independent mode first (bits
DUAL[4:0] = 00000) before reprogramming the interleaved mode.

DUAL[4:0]? Those bits don't exist! It's refering to the MULTI[4:0] on the ADC_COMMON register!!
Anyway it doesn't work that way. I also need to reset the DMA bits in that same ADC register and put them back.

For the last instance, I tried a small delay in the Main loop, between conversions, and guess? It became in the delay!
After some cursing:

Code: [Select]

void SysTick_Handler(void)
{
  /* USER CODE BEGIN SysTick_IRQn 0 */

HAL_IncTick();   //<---------------------------This wasn't generated by CUBE IDE!!!
  /* USER CODE END SysTick_IRQn 0 */
  /* USER CODE BEGIN SysTick_IRQn 1 */

  /* USER CODE END SysTick_IRQn 1 */
}
What the hell? Missing one of the most basic and important parts?
Why I have to feel frustrated 24/7 using this?
I'm pretty sure I will drop STM32 soon and get a 300MHz SAMC from microchip... Or learn ESP32!!

Tomorrow I'll have a look at the Visual Studio+VisualGDB combo. But the CUBEMX is the same so...
The worst is that I don't  need to code anything.
Now it had become a personal issue, why doesn't it work? Wanted to clear up the matter so badly 

[dreamcat4]

And really the only platform i can actually think of which satisfies all of those requirements well right now (2020) is ESP32. It also has 2 cores so potentially can drive the display off a different core than thesoldering  tip.

I wrote that comment a long time ago. Sorry for saying it... Because the comment is badly informed. I was since corrected on this point by somebody else who is more knowledgeable. The ESP32 is not actually going to make any improvement (at all). In fact ESP32 has it's own problems / issues. And could be worse. It is not so suitable for this application. Other MCUs are a better choice.

[EDIT] Specifically the ADC on the ESP32 is utter garbage. And when you switch on the built-in Wifi... well that will inject interference spikes all over the sensitive op-amp gain stage going into the ADC. So bye bye to accurate temperature measurements. You would then have to add an outboard adc module, and physically distance it away from the ESP32 and it's antenna. Doing all of that might perhaps be a fun experiment. But does not seem worthwhile. Compared to just ditching the wifi (because you don't really need it for this application). And instead just using a faster MCU from a different manufacturer. [EDIT2] not that we need a faster MCU it seems? all except for driving more advanced graphics to the LCD. Which (again, we don't really need for a soldering iron).

[mikes]

Sorry for saying it... Because the comment is badly informed. I was since corrected on this point by somebody else who is more knowledgeable.

Actually, it isn't, and you're arguing against yourself. WiFi obviously isn't needed, and I mentioned the need for an external ADC (<$3).

But my comment wasn't necessarily specific to the ESP, it's just something I'm more familiar with (ESP32-DevKitC). The point was broader - there's so much work being done simply to keep up with all these variants that is seems some common replacement controller would make sense.

I think the ability for anyone with a PC to easily flash the code without needing additional hardware is important. So, USB and a bootloader, basically.  Devboards cost less than the sum of their parts for low quantities, and would make construction simpler (a whole lot of SMDs already soldered for you). I believe Blue/Black Pills also support a bootloader which allows flashing via USB. Looks like I can buy one of those for <$10 each on Amazon. But, I understand there are potential issues with getting a counterfeit, not-always-compatible STM32 on the generic boards. I haven't seen any similar issues with the ESP32 stuff, and you can get a genuine one from a distributor for $10.

[dreamcat4]

Mikes those are totally some good points. And I agree with mainly the ease of development aspect you brought up. Wheras we mostly? Don't seem to need the extra performance or features offered by ESP32 platform. From the perspective of ease of development, I do not wish to discourage anybody from trying to develop on ESP32. So long as you understand the limitations. But also I think we don't understand each other in terms of the cost of those ESP32 modules. Because they used to be about $6 each? I think? This was significantly higher than the cost of other MCUs.

In terms of using an ST MCU with usb DFU for firmware update. Then the TS100 open source firmware has already achieved this on a fairly low end STM32 series part. So it would make sense to borrow code from that project, it already being open source itself. Rather than try to reinvent all thse aspect for STM32 platform by ourselves. And that is still a lower development cost (efforts) than doing somethine else as radical as, for example, switching over to ESP32.

Another point about the Blue pill.... it's not clear ATM why David's blue pill actually died. However those specific chinese clones on the blue pill are 'fairly close' to a real F103, aside from the different Product ID code. Anyway... to be sure of a genuine ST part here is a link to purchase a "black pill" on aliexpress. On those boards is a low pin count STM32F4 part.

https://www.aliexpress.com/item/4000679874594.html

Please note that the above product ^^ seems to be priced somewhere 'in between' the cost of a blue pill chinese clone. And the cost of an ESP32. And it's performance is also somewhere in between.

I uhm... don't actually fundamentally object to other MCU platforms based on their merits. Because many different platforms would be more than capable of this task. Rather my objection is that by splitting our efforts... then collectively we achieve far less in terms of compatibility and features. Wheras if we just stick along with 1 main platform then it is far easier to keep a common codebase that remains compatible with the most number of different hardware configurations an features.

This same argument also goes for incorporating support for extra different tips beyond the T12. Including the various different JBC cartridges.

At this point I have seen multiple other 'worthwhile' GPL open sourced hardware + firmware projects for T12 and JBC 245 on github. Probably about half a dozen or so. However they all suffer from this problem of being completely isolated and fractured development, requiring a specific unique hardware design. And either having poor performance or 'whatever bugs and issues' that stop them from being a seriously usable and dependable product.

Adding another project to that growing list seems like a complete waste of time to me. This is why I generally tend respond overall negatively to the constant suggestions of switching to different MCU platforms. Without enough serious justification.

I think the short answer is that USB dfu on STM32 should be possible. However listening to DavidAlpha here, it would seem that there is not enough space on the cheaper versions of STM32 family. So perhaps if it is possible, then it should be considered for a compiled in/out option. So that the lower end parts can still share the same unified codebase. This is my opinion until somebody else independantly comes out with a kickass controller based around ESP32, all done for us complete with support for JBC tips, etc... which you never know! Might happen.

Until then my preferred (next best) alternative to this project happens to be an arduino based controller. Which was designed specifically for the JBC tips only. But that is not of concern here! Just some other pet project.

[DavidAlfa]

In fact I refuse to keep developing for 16/64 RAM/flash devices.
As I said before, the firmware is done in a way that you can't control the used RAM.
It's all ok until you add few more lines of code and suddenly the stm32 directly boots into the hardfault interrupt, with no way of debugging.
Delete the Splash logo frees up few bytes and it works again. Or deleting the new code and keeping the logo...
The compiler tells that the flash usage is 99% full but then the RAM is other thing, you might think you have free RAM, but malloc needs all the space you're allocating to be contiguous, then you no longer have that much usable RAM.
I don't like the malloc usage in mcus. It's ok in a system with lots if RAM, but not here.
Since using my 32f429, I only had one hardfault, which I quickly debugged  and found to be a uninitialized pointer.
A breeze in comparison to the smaller one.
The fw should be re-done allocating everything at compile time.
Not sure if it worths the effort...
About the USB, stm32 already come with USB DFU so it should be easy as pulling boot1 high: ( Don't get confused, he's downloading an additional bootloader to the flash)
https://ardupilot.org/dev/docs/using-DFU-to-load-bootloader.html

[dreamcat4]

Ah interesting...
Dropping the support of F100 and F072.... that seems OK to me. They are not really worth the time to support IMHO.

But for the mainstream ones... Looking up these various products, it would seem that the 48 pin MCU on the blue pill is too small then? Since it is 20k ram, 64k flash, then you are suggesting instead to transplant the F4 from a Black Pill? However is that the cheapest cost option? Perhaps there are some  other F103 parts with more memory+flash.

Wheras on some of these other PCB, they have the pads for 64 pins LQFP package.  For example on my Blue PCB. This is the cheaper RCT6 sku.

https://www.mouser.co.uk/ProductDetail/STMicroelectronics/STM32F103RCT6?qs=%252BB84zevwoRA6TYzZIgOIoA==

.... which has 48k ram, and 256k flash size.

[dreamcat4]

OK, so I am looking through SKUs in the STM32 MCU Finder. And it seems the STM32F103  that are packaged as 48 LQFP... those ones all max out at 20kb ram. This is only +4kb more than the amount of RAM you specified, so is that too small? This would then mean dropping support for all F103 mcus on the 48 pads boards.

Anyhow (just in case) the best 48 pin parts with only 20kb are:

F103 Series

* STM32F103CBTx = 20k/128k, package: LQFP-48 (preferred), bulk price:$2.23
* STMF103CBUx = 20k/128k, package: UQFPN-48 (not ideal), bulk price: $2.24

F3 series, the RAM increases to anywhere from 24k to 48k RAM. The max flash + max ram SKUs are:

* STM32F303CCTx = 48k/256k, package: LQFP-48 (preferred), bulk price:$2.56
* STM32F358CCTx = 48k/256k, package: LQFP-48 (preferred), bulk price:$2.89

F4 Series

* STM32F413CHUx = 320k/1536k, package: UFQFPN-48 (not ideal), bulk price:$4.94
* STM32F423CHUx = 320k/1536k, package: UFQFPN-48 (not ideal), bulk price:$5.26

So for the replacement 48 pin part... (as cannot solder anything else to those versions of the PCB)... maybe the F3 series is a better one to target, instead of the F4? Because the F4 series does not come in the LQFP package, which is easier to solder than the UFQFPN-48.

Looking on my Black pill it has the following MCU,

* STM32F411CEU6 = 128k/512k, package: UFQFPN48 (not ideal), bulk price: $2.80

Ah-ha! So we finally see the reason why black pill is on F4. The cost of that version of the MCU is the same price as an F3.

I don't know what else to say ATM, except that it seems a bit unfortunate that the F4 series does not come in LQFP package. I think people can still solder the UFQFPN package instead, it just requires hot air station. And is more difficult to do.

So mostly I suppose we shall see, DavidAlpha, how much ram is needed coming up. And will get a better understanding about that later on.

Until then, know that the thresholds for RAM compatibility are:

* 20kb for F103, package = LQFP-48
* 48kb for F3,  package = LQFP-48
* 320kb for F4, package = UFQFPN-48

That ^^ applies only necessary to the 48 pin pcbs. Which is the 'worst case' situation. Because other PCBs have 64 pads. Those 64 pin count options can be found with extra memory.

[DavidAlfa]

Oh, I didn't mean to throw it all away and close the door!
Actually the firmware is prety well done and it shouldn't cause much pain to work on it, I'm totally open at porting it to new mcus.
What I meant was  not not break my brain enhacing it much further... but I still have some ideas!

But when the flash 97% full, and you think on adding new stuff... ok let's do it...
An hour later you see it doesn't fit. Or it fits, but crashes without explanation.
It has happened to me to the extend of adding a single variable and causing a Hardfault!
And you couldn't debug it! The debugger directly started at hardfault... before using git this was a very painful process.
Then I really appreciated de diff view.

Suddenly, you delete an unused static variable "uint16_t temp", that you had left behind when debugging something, that was doing absolute nothing, being used nowhere...
And it was working again! I got so fed-up of that kind of unnecesary headaches, that I decided to stop for some time.

For now, I've been porting an old stm32f429 project, an oscilloscope from a german programmer, and adapting it to the new HAL libraries, as a self-training experience.
This project uses a lot of peripherals in advanced modes, so I'm learning a lot, specially timers, ADC and DMA. The datasheet is close to burning too 
I think when I return to the T12 in few days or weeks, I'll have much clearer ideas!

I also looked for better, compatible stm32s last week. Don't need to swear that we both went to aliexpress like a bat out of hell!
Reached the black pill too... very nice mcu for the price. But the FPQ have two problems.

First, the QFP48 drops exactly in the inner part of the QFN48 footprint. Extremely close but the pins won't match.
The inner distance of the QFP is 7.3mm, while that same measure is the QFN's outer.


If the footprint in the pcb is bigger, then maybe it can be done.

Another problem it's located in the supply pins.
There are minor diferences, the pin 22 is Vcap in the STM32 3xx and 4xx series, while in 1xx and 0xx series it's a GPIO.
Not a big deal unless that pin is already used.
Yes, people like us can cut, solder, burn, replace, scratch and break with no problem, but most people just wants to flash the stock board.
The stm32F3xx are a nice step forward in capabilities. In a board with an unused pin 22, just scratch, solder a cap and go...

The QFN is not that hard to solder by hand though. A nice tip and few lbs of flux will get it done!
The main issue is that you won't be able to solder the bottom  ground pad.
Will work anyway, however the signal noise ratio will probably suffer.

About the mcu specs... I think the 20KB will be ok.
4KB extra ram is plenty of RAM for an already done firmware that doesn't need any more.

The problem was with my 072, the poor thing was having a hard time, like women in their 50's trying to get into the 20's wedding dress
(Also men do! Everybody's searching for something to get offended these days haha)

[dreamcat4]

Wow - thanks for checking these details! Very thorough. Also very nice to hear about the 20kb ram limit not being an issue for the F103.

Yeah the PCB pads can be intentionally be sized halfway inbetween either type of package. And it will work fine for hot air. In fact the pads on my green pcb oled (v3.1) have the longer fingers for accomodating LQFP. Yet it came from KSGER with a QFN soldered onto it instead. Seems to be fine.

 

[DavidAlfa]

Finished the stm32f429 thing... I understood most of the libraries, but the DMA2D and LPDC...huh, they make manuals for people who already know how to use these things.

Now back with the T12. Had to find a way to reduce code usage...
When enabling a font and using just one character, the flash usage increased a lot.
So its seems the compiler can't optimize the font tables...

I adjusted the fonts so they only had ASCII chars between 32 and 127 (The basic ASCII set). And replaced the '~' data with the 'º' (The only extended ASCII code used in this project).
The flash usage went down by a 22%!... Much better.

This is what I planned to do. Reserve a fixed small PWM time from the PWM total period, limiting the max duty.
In the case of a 50Hz PWM, we take 1mS for measuring... that gives 95% Max  PWM duty. Not a big loss.
At least we are doing that with absolute control. Is there any benefit on going to higher pwm frequencies for "slow"(From a micro-second perspective) heating a resistor? I don't think so?
With 64 conversions, it takes 64uS to teh ADC, so it would be nice to know the  PWM output fall time and adjust the dead time.
I tried to paste here but the usual tab havoc happened


Time to dust off my old Philips PM3055 60MHz oscilloscope. To do it right, I also have to ensure that the cap in the amplifier doesn't discharge, that would void the iron detection.
Errr, the Vref and Vsupply channels are useless. So they'll be removed. Or maybe sampled later, outside the PWM off timelapse.
Sadly the tim17 timer is very basic, only provides generic interrupt. Would have been great if it had trigger output, so the second timer started automatically without the need of interrupts.

 

[floobydust]

50Hz PWM is fine, I kinda don't like the 5% power loss though. You might not have to sample temperature so often?
Take a look at T12 Hakko Patent US6087631A using 1/2 mains-cycle sample rate but longer PWM; includes the oddball thermocouple lookup table.

The thermocouple temperature measurement blanking-time is really important.
You need time for the mosfet to switch off and D-S capacitor to discharge. One guy said 500usec was plenty including the time at the end for doing a burst of say 10 fast ADC samples.

I thought some good work was done here: https://www.hackster.io/sfrwmaker/soldering-iron-controller-for-hakko-t12-tips-on-stm32-c50ccc
Might be worth a read: http://dangerousprototypes.com/forum/index.php?topic=5264.0

[DavidAlfa]

That was just an example!
Actually it worked pretty well with 60uS dead time, although some spurious noise appeared from time to time (sudden 10ºC jumps).
I know that it works because when I plug a totally cold tip and set the power to 1%,  it measures 60ºC which is the lowest it can measure, so there's no power there.
The ADC is always sampled in the moment that PWM output goes low, so the duty doesn't matter here.

At 80uS it appeared to stop doing it, I finally set it to 100 for better clearance.
The ADC takes 91uS to send 64 samples. Total time about 200uS = 1% of the PWM .
But because I'm also sampling the NTC. If I do it with 16 samples and only the iron tip, that would be 23uS. So 130uS loss at most. That is 0.65% loss.

With this method actually the power delivery is pretty awesome, it heats up to 350º in 6secs and stays +-3ºC.
Also you can hear the PWM being totally constant without strange noises. The good of doing synchronous measurement.

Next I'll trigger the ADC again while the PWM is operating to get the rest of the measures without disturbing it.

[DavidAlfa]

Some playing with EMA and DEMA filtering.
First I tried EMA, but it's slow and undershoots (causing the PID to overshoot), and causes oscillations.
If you adjust the pid, it will work on that range, but big changes in the temperature will cause oscillations again.
So, now I'll try the DEMA... its faster, but overshoots a little (opposite as EMA) looks nice on excel.
If anyone wants to play with it, I attach the excel sheet too. You can quickly modify the filter factor, ADC noise and ramp rate.
The noise is generated randomly around the configured value

[dreamcat4]

Wondering if either of those methods... if would work better along side to work with the other algorithm, instead of PID. It is possible to replace PID. The thing guy on the other forum thread shared his C code. Sorry I cannot remember the name of it right now. It was linked previously.

[DavidAlfa]

Yep, that was my next task, I'll see how it performs.

[DavidAlfa]

Well, my last tip died.
This one didn't overheat, the temp started to jump back and forth making the system PID crazy, in last instance I notice it measured 400ºC though it barely could melt solder, and a moment later it stopped working.

I dismembered the dead tips  and what a deception. The rigid wires that go between the heating element and the connector had wayyy high impedance, in most it had ~0.7ohm( I cut 6 and set them in series, it measured ~4ohm).
So from 72W, 60W are at the tip. and 12W at the wires! I guess (I hope!) this is not the case of genuine Hakko tips.

One of them looked better, with thicker wires, but no! It must be a different material, was 1.6ohm per wire! 3ohm in the wires!
I remember one of these bastards heated like hell, so much that the nylon in the connector had slighly melted. After a while of soldering you couldn't hold the handle anymore!
That must have been this tip. No wonder why,  27W in the wires, 45W in the tip...!

I might even lower the voltage to 18V or so. The PWM rarely went over 50% even when soldering big ground planes. The heat transfer is not that good.
How do the fake JBC tips do?

[floobydust]

I think most of the software work is in the fault handling.

The cheapola T12 clone tips are notorious for having bad connections. Either the handle's plug or the crimp collars go bad, so you intermittently get an open thermocouple/heater.

Depending on the thermocouple op-amp circuit, this would be seen as flickering between full-scale say 500ºC and the actual tip temp. You code has to constantly check for open TC. They really need to add the standard 1MEG pull-up to the TC input.
Other op-amps will float to the lowest TC temp which might be why your PID went too hot?

If the tip temp keeps climbing when heat is off, the mosfet is shorted and hit the beeper.
You can also model the total heat input to the tip (simple integrator) as a sanity check on the temperature reading. Yes you don't know the actual heat load (wet sponge, soldering a piece of railroad) etc. but as an "observer" the code can keep an eye out for gross troubles.

Note I have also seen the CJC value get corrupted and go to a nutty value (or overflow a variable), which software can run with. Would you expect CJC of -100ºC ? Well, here in Canada I have soldered outdoors at -20ºC but I saw the KSGER S/W screw after up the sign change because likely an unsigned int. is used.

[DavidAlfa]

All those bugs were fixed since I started working on the firmware. There are no bugs on the temperature sensing or PWM generation, all the posibilities are taken in count.
If the handle circuit breaks, it will measure a very high temperature, so there's no danger.
In the instant of aN open circuit it measures 650ºC. The PID goes to 0, the gui disables user controls and shows NO IRON.
While no iron is detected the PWM is limited to 1%.

The old fw had a very weird NTC algorithm that absolutely didn't work.
I only burned a tip ever by a software error, and it was few days ago due the compiler not taking a define correctly.
Otherwise, all the other 3 burned tips were my fault by debugging and halting the core with PWM being at 100%.
I always disconnect the handle when halting the cpu, but you only need one mistake!

When this tip failed, the temperature rised instantly +50ºC when the power was on and the next cycle -50ºC. So it was something wrong in TC.
That tip had been done that randomly since last week. I knew it was the tip and not the software because all the rest worked well.
I've debugged the timings and it's like a swiss clock.
When the hardware sets the pwm low, triggers a delay timer, the timer triggers the ADC, the ADC interrupt resets the adc, calculates de PID and the cycle starts again.
So everything is isolated from the main loop, the PWM or the ADC won't miss anything because the gui is busy drawing, for example.

I've found this and it's very tempting! JBC handle + 2 tips for 30 bucks!
https://es.aliexpress.com/item/1005001530229488.html

Edit: I bit the bulled and bought the JBC ! Canceled the T12s

[cosmin1]

I can try draw the schematic from your pictures of 2.1S r3, the board is very similar to 2.1S deluxe version with the desoldering option. Black solder mask is no fun.

Today i received my STM32F101RBT6. Because of poor chinese packing, pin64 was too bent and when i tried to push back, it broke. From what i measured, pin 32, 48 and 64 are internally connected together (they are all VDD). So i suppose i can use it like that without any problems.
I was a bit predictive and orederd 2 chips, so anyway i have one chip with pin64 broken and one chip complete. Just in case...

[DavidAlfa]

Try, if it doesn't work , then you'll  know it was important !

Now the problem is your fw, where do you get it? Do you have stlink programmer?
You can be a guinea pig that will propaby die or result seriously harmed/ disabled tester!
Once I got few more details we can try t if you like

[cosmin1]

I don't have the firmware yet and neither the STlink, but it should come in few days.
I just finished my schematic and passed over to floobydust. He will have a check and we'll see how to find a firmware.

[DavidAlfa]

Was it a Ksger v2.1s r3 in the end?