CFW for KSGER/Quicko STM32 Soldering Stations

[dreamcat4]

I have 2nd blue board f103 here. And it looks like the regulator is switching type, but at 1mhz. It is supposed to be ok according to other user reports. So the recommendation is to not replace it, instead of that DavidAlpha's capacitor noise smoothing. But check the circuit because these are a bit different from version to version.

The op-amp is unknown. There is no way to find and specs on it. So only replace if you have reason to believe it is bad. However you might instead have bad tip.

The crystal is not known.

For restoring, you are taking a risk. If you can manage to restore successfully. Then there will be a lock code after re-flashing. The key gen, and the eeprom will be cleared.

There is no DavidAlpha build yet for this version. It is yet to be generated. But he has put step by step instructions in the readme.

I still have to order soldering temp tester. The main reason I don't progress here is because I first want to document performance of the closed chinese firmware. As a baseline. This is not so much for the sake of knowing relative performance. But more to characterize the behaviours. To notice any bugs or weird behaviours if that occur in the open firmware. Since we are testing on a variety of different hardware boards. They are not all quite the same as each other.

For example if the board I have here has inferior component, such as crystal. And the closed firmware included some workarounds they fix in that. But DavidAlpha does not see that as a problem, because his circuit is different to mine.

I do not want to stop others from trying this software. It should be encouraged! For moving the open source development forwards. That is a good thing! Just be aware in case of unforseen issues.

 

[dreamcat4]

May I ask why is the original firmware so bad and need alternative firmware?

Sure! Actually the original firmware is not so bad... For the most part it works quite well. However that does not mean we don't also need the option available for an open source firmware too.

It should be a free choice to users whether they want to play it safe and stick with the closed firmware. Or if they want to flash over it an open firmware. Just like the with TS100 iron. Same situation.

I do not discourage anybody from using the closed firmware. It is just a set of trade offs with different positive and negative for each one.

So if the closed firmware already works, why bother? Why make such efforts? Here is my attempt to list out, to explain the many motivations, for why to do this:

Reasons why we DONT want the closed firmware:

* The closed firmware is fixed. Due to the way it was developed, it does have the capability to be improved with new features.
* The closed firmware has lock code. Bad! We don't want that!
* The closed firmware cannot be dumped fully, so it cannot be reflashed if your build is not already one of the few versions available
* If the closed firmware boots into Chinese, and you don't know the chinese symbols... then it is also annoying to find the language menu. To change the language.

Reasons why we DO want an open firmware:

* By contrast, the open firmware can be recompiled for specific hardware, at will. So there is no worries that your specific board can be recovered back to an open firmware. Once that version of the hardware becomes tested and supported. Of course it isn't yet.
* We can change UI, menus, fonts, and use more memory. If the MCU has more memory.
* It gives the possibility to later on, maybe add support for other handles / tips. For example JBC T245. And other JBC tips.
* It gives a better trust in the equipment. If there is a problem, you can see where that is happening, in the source code.
* It permits open hardware also, to be supported with a common source code. Which then also means... the possibility for hardware improvements. Which would never be possible with a closed firmware.

For example:

* It gives a possibility for diagnostics / data monitoring features. Going through SWD, or through UART serial, back to the PC.
* It gives a possibility for USB DFU flashing. Like on the TS100.
* It gives a possibility for USB-PD over usb-c. With a separate outboard chip for handling the USB-C.
* It gives the possibility for other features, whatever you wish to add. Limited only by your knowledge, and imagination!
* The whole community can then benefit from all these improvements, for free.

Finally:

* With an open firmware, then we also do not need to buy as much the hardware from the KSGER or QUICKO manufacturers. Or other aliexpress / banggood sellers. For example if they do not make it a good enough product. Perhaps for cost reasons, or some stupid oversight, or lacking protections, which causes a fire etc.

From your video I can see that there are some things missing that are present in the original one. Like stepping, startup behavior.

Some features are disabled for memory, others are removed because they are not used often, and it helps to reduce the burden on the user to scroll past menus. Also: If a preferred option can be compiled in then it does not need a menu! You can just recompile it yourself, reflash. And you have your preferred option always-on.

[dreamcat4]

Also i can sacrifice the one with 61jlv U3 op-amp to flash it.

Actually the op-amp on other board is another different, the SOT23-5 package with marking 621K1911. This smd package marking 621K1911 is also not identified either. So you have 2 unknown op-amp.

 

So IDK maybe if you swap over just the op-amp. It they will both still work? Then your 2nd board with the F103 will be just like my one. And we can both use the same open firmware builds. Rather than have 2 different binaries for the F101 and F103.

The other thing however is that I must wait... another month from China. To get my RST FG-100 tester.

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

Until then, I cannot take accurate temperature readings. Since my other temperature sensor reads consistently a -100C different than the iron. For all my irons, including TS100, etc. So my readings are not accurate enough to be useful. Maybe because it's not designed specifically for this task.

 

Well no matter the reason, new RST FG-100 tester should fix that, for $12. It will just take another month to come.

And the KSGER carbon fibre handle (from KSGER store). Should come at about the same time. Since I just only order them both right now. In the last 2 days.

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

Is there an option to flash it back with original firmware and then activate it with codes, if your firmware will not work?

If you can reflash the right build, that is compatible, then yes maybe. However what if you cannot get the right hex? I searched already for this same Blue PCB. And did partial binary diff. None of the available .hex matches. And I have downloaded and checked all of the available closed firmware .hex / .bin available.

You will never know if it works until the point of flashing. So "maybe". Or maybe not! That is why to recommend buying a brand new STM32 mcu, that is pin compatible with the pads. You understand?

I have no reason to flash this for finding. Until maybe another 1-2 months. At earliest. Or perhaps never, because I actually have the spare MCU. Plus also I have v3.1 green pcb kept on closed firmware. So it would not be time efficient for this project, to waste the time check that. Since everybody else has many different boards. Only a few people actually have these same blue PCB.

I saw on the Russian google drive some dumped hex files, are those original dumps from KSGER and how do I identify which are suitable for which?

The process is to try to flash all of them. And if any will boot, then it will show the display. At that point, if successful. Then it will ask for code.

OR there is no compatible .hex available. Then you are forced onto open source firmware. With no way to restore back to original.

 

[DavidAlfa]

My firmware is prepared to be used with the hardware peripherals.
That is, I don't have i2c implemented using software.  And those ksgers are using it that way.
It might be the reason why the stock firmware is so incredibly slow.
Mine did like 3fps amd moving through the menus was pain. Would move one step forward, then backwards.
And it used 1KHz PWM, so you heared a loud beeping all the time.

In my case the modded fw it's much better. But there might exist well done firmwares.

I've just committed the last changes as beta release. I hope not to be too arrogant  . Pretty stable I must say.
Added some safety measures to make sure the PWM doesn't freeze in a high state when a system error occurs.
System settings checksum a boot and also while running (to save the settings), so I don't have to make a thousand functions for saving each bit.
And much more...A lot of effort in polishing small errors in the graphical system that caused weird representation.

But I'll be off for a time, because while handling te the handle wires, they slipped off and fell down exactly on the discovery board that I was using as stlink.
Yep, almost 30V to the poor thing. Luckly my computer didn't screw up too.
The MCU is cooked, it burns after few seconds, but somehow it's still is able to blink a led in it's agony
So time to get a stlink and another 103 for my discovery board.

[dreamcat4]

Cool man! Not able to progress either, and for same reason: waiting for parts from China. All good.

 

Dropping metal conductors onto live board... is also something I can relate to. It's pretty easy to do! So no worries. Sometimes current limiting the bench PSU supply can help protect against shorts. But often that is not possible. Including when powering *not* from the bench supply. Which was how my mosfet caught fire.

BTW - just wanted to say that my repair friend has gotten back to me. And measured his Genuine Hakko tip. It is:

8.22 ohm

So that is the correct impedance. Between the 2 inner most pins heater + and heater -. To compare against chinese clone tips. I will forget this number! 8.22 ohm. Also my equipment is too cheap to measure these low resistances accurately enough!

 

[DavidAlfa]

Got 5 STM32F103CBT6 (128/20KB version) for 5euro. I hope they work.
https://a.aliexpress.com/_BOUYuD

Also a cheap stlink to play with. A quick Google trip revealed how to mod these to add more features.

https://pikabu.ru/story/delaem_stlink_v21_iz_kitayskogostlink_v2_6494848

[dreamcat4]

Got 5 STM32F103CBT6 (128/20KB version) for 5euro. I hope they work.
https://a.aliexpress.com/_BOUYuD

Here is good forum thread, many examples to help identify the genuine from the fake ones:

https://www.eevblog.com/forum/projects/do-you-have-an-stm32f103c*t6-looking-for-your-help!/

Hope that helps! Well worth reading.

Another maybe useful? Suggestion is to look at the bulk pricing. For example here on mouser, you can see the prices:

https://eu.mouser.com/ProductDetail/?qs=WxFF5lh7QM3goh6GV5Ogig%3D%3D

In ST MCU Finder tool, it shows $2.236 is the lowest cost they can be purchased from ST, the manufacturer. So unless it's overstock, obtained 'for free', or recovered from a defective failed board. Then the price should be more, to expect a profit by splitting / reselling in smaller quantities.

Perhaps another approach is to recover (by yourself) from other failed or broken device. Because these STM32 are used in so many product these days. All around us.

[DavidAlfa]

As long as it works... Haha.
In fact all the 100xx series seem to be the same all have 128kb and USB, supossely the 100,101 are cut-down versions (some might have defects, some not, it's a lottery), but chinese know that and program the 101 with 103fw, they usually work, with usb and everything !
That might explain why I could allocate up to 20KB ram before crashing my 072... It might have 20KB too!
This must be tried seriously. Modifying the linker script so the compiler uses all the thing and making a program to test the whole ram and flash.

Remember the the arduino T12 project I posted yesterday ?
The git page is great, has a ton of technical details. Like the op-amps, settle time...
https://github.com/wagiminator/ATmega-Soldering-Station/

I also found this. If you want to make your own Jlink (12MHz clock). And a lot of details on to change the firmware serial in case it gets blocked.Yep, I don't think it's too legal, don't use that professionally :
https://github.com/Kevincoooool/MCU_Link_Diy

About you guys just wanting to flash a new fw, and no interest in debugging or whatever, the DFU mode worked really well.
Just need a usb/serial converter, we almost all should have one already. Check ST AN2606 for UART connections.
Connect with BOOT0 set to 1. Open the Demonstrator gui, erase, flash...done!

I'll try to use my half-dead stm32F103 clone to flash st-link fw on it...

[DavidAlfa]

Well. I'm not todo proud of this, but without iron it's pretty remarkable.
The weird CKS chip worked well.
The stlink utility refused to recover it, downgraded to v4.3 and it worked.
Not only I have a stlink, but now it works in stlink+serial+mass storage modes!
Not too bad for an already (supposedly)dead blue pill.I suspect the stmCube does something weird in the startup code to make these to not work properly.
And yes, I edited the stmCube proyect xxxxxflash.Id file, and could use 128K on the 072! (verified some flash, not whole)
The ram definitely is limited to 16K. Reading further causes Hard fault.

[DavidAlfa]

Hah! What a coincidence! Checking the flash I found an error, but not on the extra 64KB... on the "normal" flash!
That section was were the original fw keep erasing everytime, for every setting. I guess the flash weared out.
That was I feared and changed in my fw... too late! haha
In my case the bad address was 0x800FB84, it reads 0xFFFFFFFE after erasing.


So I did this. Edited these parts of the linker script:

Code: [Select]

MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 16K
  FLASH    (rx)   : ORIGIN = 0x8000000,   LENGTH = 64K
}


Code: [Select]

MEMORY
  .rodata :
  {
    . = ALIGN(4);
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    . = ALIGN(4);
  } >FLASH

Like this:

Code: [Select]

MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 16K
  FLASH    (rx)   : ORIGIN = 0x8000000,   LENGTH = 63K
  FLASHBAD (rx)   : ORIGIN = 0x800FC00,   LENGTH = 1K
  FLASH2   (rx)   : ORIGIN = 0x8010000,   LENGTH = 63K
  SETTINGS (rx)   : ORIGIN = 0x801FC00,   LENGTH = 1K
}


Code: [Select]

MEMORY
  .rodata :
  {
    . = ALIGN(4);
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    . = ALIGN(4);
  } >FLASH2

By default it seems to use little or nothing of the .rodata, but if you add a new huge font, it will use it.
So it seems that .rodata will l get used only if the .text section is full? I don't really care...it works!

Declaring SETTINGS section will ensure that the program never gets written where the fw store the settings...

The result:

[dreamcat4]

Awesome! Cool man. Thanks for explaining this. So where was the linker script?

Do you think you can copy this post, into docs? For github. It's probably better as it's own separate markdown file. Otherwise it's harder to find in the forums here.

[dreamcat4]

The problem I am having understanding... is because it is very difficult to find any information about NOR errors. Or "wearing of NOR flash". People say it should just always works. You can try to google. It is difficult to find such information.

 

There can be NOR defect at the factory. During manufacture. If this is true for your chip IDK. But if it was missed, by luck. That it did not trip over the bad address before now.

But usually when flashing, you also verify the flash is good afterwards, right? You re-read back all the bytes. And checksum compare. To the .bin. To make sure it flashed OK.

 

Only ever interacted with these MCU through "OpenOCD" program. Over SWD. I cannot remember now.

Could it be a bad flashing maybe? That is what these guys say.... Possible flashing problems for the NOR, on other STM32 series mcu:

https://community.st.com/s/question/0D50X0000AX8Hm3/stm32h7-internal-flash-error

The thread suggests if you have some bad stuck address, then "full erase" etc. To clear such issue. And get the cell straightened out.

 

It seems very strange problem. Since you have avoided it now... moving address. A great trick! Then maybe not worth trying to mess about more with full erasing etc. If this is your only one. While still waiting for the other ones, F103CBT6.

[DavidAlfa]

As I said previously, the programmer doesn't check the whole flash, only the used part.
If your code is 28KB, it will only check that.
It did never fail because I never went over ~94%.
It might be possible to change these settings somewhere.
The linker script is the STM32Fxxxxx_FLASH.ld that generates automatically when creating the project. You can open it at the root of the project, in the ide itself. Nothing special.

Now I bought an ultra cheap hot air soldering station.
https://a.aliexpress.com/_B0PhU5

My plan is to integrate the T12 inside too. No idea if there's room for that, but it's okay anyway if not.

[dreamcat4]

As I said previously, the programmer doesn't check the whole flash, only the used part.
If your code is 28KB, it will only check that.
It did never fail because I never went over ~94%.

 

Ah now I understand! Sorry for being slow... What you are saying seems to be that: after 80h there was a manufacturing defect in the NOR flash, so this part was binned as 64k part at the factory. So it always was a defective address.

So other people, who also want to unlock other chips using same method. They might have to define different usable regions, of different sizes. If their defect(s) are found at other locations. Which are not so close to the beginning of the next segment.

What would be even better, is a way to declare bad address locations for the compiler. To insert Jump instruction. To skip over only exactly the bad address segment. That is - if the segment is program code. Or some type of memory remapping for other segment types, like data.... But that would be more difficult. Perhaps not worth the trouble / efforts.

So long as these Chinese clone chip behave same for the IOs, ADC, etc. No worries.... the problem is when they do weird stuff. That deviates from the expected behavious, of the official ST parts.

Now I bought an ultra cheap hot air soldering station.
https://a.aliexpress.com/_B0PhU5

My plan is to integrate the T12 inside too. No idea if there's room for that, but it's okay anyway if not.

This station is from the 858d family. I have similar. It is never going to be a tool you will want to keep. Because the fan is in the handle. This means that the performance is limited.

So I would not recommend you try to integrate into that specific model of shot air station. Because you will most likely want to upgrade to a more powerful hot air station later on. Same situation here myself.

[DavidAlfa]

For the use I'll give to it, very ocasional, it'll be ok.
Yes all c8t6 are the same as the cbt6, all have 128K but upper 64kb are untested or have defect.
As I said, I don't know if the failure came from factory or was caused by the excessive flash wear by the firmware settings routine...
It works just selecting the CBT6 part instead the C8T6! The IDE nor the programmer complains.
No need to test anything, if your program uses a bad flash address it will fail verification.
I tried inserting a variable in the flash at that address, it didn't work when the program growed, the linker complained because the sections were overlapping.
So I had to make different sections.
Luckly assigning the .rodata section to the second flash space worked well.
This is just a dirty trick while I don't replace it. Or not...if it works, why spent money... Of course only for the DIY world.

[illiac4]

I have ordered another one to see how it does.
The seller has said that it is stm32 based and it cost only 32€ incl delivery.

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

[DavidAlfa]

Ask for internal photos. Their photos and the customer reviews show that it's using the STC chip, not the STM...



Checkout this:
https://www.eevblog.com/forum/index.php?topic=160627.msg3352410#msg3352410

[illiac4]

I have asked him:
05:20
On some reviews I cee that it is sct and not stm32 as stated in description. I can also see that some people did not get the tips included?

06:51
hi,friend.it is 5 Pin Stm32 station
we used sell STC,now all STM32

[cosmin1]

BTW - just wanted to say that my repair friend has gotten back to me. And measured his Genuine Hakko tip. It is:
8.22 ohm
So that is the correct impedance. Between the 2 inner most pins heater + and heater -. To compare against chinese clone tips. I will forget this number! 8.22 ohm.

I confirm the same resistance on T12 clone tips. I have a few and all have the same resistance ~ 8,22 ohm.


A friend got same board as mine, but is marked v3.1 and uses STM32F103. Mine is STM32F101.
Same HW 2.00, same SW 2.12. So i suppose the flash is the same.
Just 1 difference: board with F101 is much more brighter than this with F103.
The brightness is a firmware setting?

[DavidAlfa]

The brightness depends on both hardware and software.
At hardware level it has a resistor for the Iref.
And it can be adjusted by software, but based on the current set by the resistor.
Also the oleds have the burn-in issue, they will loose brightness over time. Specially the blue color.
Now make the equation: oled + blue + Aliexpress -> And you get the point!
Are you sure it's not adjusted in a lower setting?

The 101 is a cut down version, but nothing is really disabled, so all the extra stuff from the 103 could used at your own risk, it might fail, or not.
I'm almost 100% sure that they put the 103 firmware on it.

[cosmin1]

At hardware level it has a resistor for the Iref. - Can you tell me which resistor would that be? It can be found on mainboard or OLED board?

Also the oleds have the burn-in issue, they will loose brightness over time. Specially the blue color. - These OLEDs/controllers are both new, so could be only a hw/sw difference.

Are you sure it's not adjusted in a lower setting? - What do you mean? Is there a setting for the brightness?

I'm almost 100% sure that they put the 103 firmware on it. - So can i use any 103 firmware from Github or they are different, depending on board layout?

[DavidAlfa]

It can be found on mainboard or OLED board?

In the board. But I wouldn't touch that. You might reduce the life of the screen.

What do you mean? Is there a setting for the brightness?

I don't know, you must navigate in the menu and see if there's a brightness option somewehere.

So can i use any 103 firmware from Github or they are different, depending on board layout?

The board layout is absolutely important. The firmware must match all the inputs/outputs and it's connected devices.
What I meant is that the 101 can be flashed as a 103.
But the peripherals, memory... that the 103 has over the 101, will be a lottery.
They all use the same silicon, but on the lower versions (less memory, less peripherals) those parts are not tested, and might be defective.
It's just a matter of flashing it and if it works, you are good to go.

[DavidAlfa]

I've been fighting to fit all the gui. No way. The widgets system needs a total rewrite.
It's absolutely unnaceptable that the settings screen take 6.5KB RAM!
I already said it before, the way the gui was written looks more computer-oriented than for compact, low memory devices like a MCU.

[cosmin1]

In the board. But I wouldn't touch that. You might reduce the life of the screen.

I don't want to light the room, just to be a normal light as other OLED's.  So which resistor would be? Taking as an example the floobydust schematic i attached.

I don't know, you must navigate in the menu and see if there's a brightness option somewehere.

No, there's no such a menu. It's a pretty spartan menu with only few options, as you know.

The board layout is absolutely important. The firmware must match all the inputs/outputs and it's connected devices.
What I meant is that the 101 can be flashed as a 103.

I thaught so... On absolutely the same board but with different processors, firmware would be the same. If even something minor is changed on board, the firmware will not fit. In my case, most probably they match.
But only testing will reveal if any of existing versions on Github will really match to this board.

[DavidAlfa]

This is the OLED schematic, might vary a little between makers, but the 30-pin OLED is the same, so you only have to follow the trace to the resistor from pin 26.
Compare the resistors, maybe they actually have different values.
My display have 820K. But according in the datasheet, the lowest recommended value is 760K (Max brightness)




for example, this display uses 910K...


For more details, check the datasheet, page 26: https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf