CFW for KSGER/Quicko STM32 Soldering Stations

[Bozog]

1. Yes
2. That is it 200 + 40ms
3. The clone tips have an error of similar magnitude, but it is positive (over read) - the hakko error is negative (under read) for example:
Hakko tip sleeping at 150° with 0% pwm, the instant you wake the iron pwm is 100% temperature drops to 130°C - doesn't really effect operation, just doesn't look right.
Clone tip sleeping at 150° with 0% pwm, the instant you wake the iron pwm is 100% temperature jumps to 170°C.
The problem comes close to set point, the hakko tip is actually hotter than the stm knows - so it is easy to overshoot.
Of course the clone tip the opposite, close to set point, iron is colder then we think - less chance of overshoot - we can run more pid gain - possibly it even works better than no error!
4. Can't really remember, I don't have it anymore. But the clone tip worked fine and the hakko tip worked ok but maybe did seem a bit funny.
5. This does not happen with the quicko firmware, I believe this is nothing to do with burn in - it is ksgers pid autotuning.

[Bozog]

The quicko firmware I had was pretty old. It did not even seem to have proportional pwm control - it seem to either be fixed at for example 1% or 99% and the proportion was achieved by missing cycles, kinda like ac burst fired control.

[DavidAlfa]

Today i erased the flash by mistake on my quicko    , so if you want i am ready to test some code. for the record i own another quicko , the pcb is exactly the same but the mcu, in the working one there is an stm32f072(as davidAlpha build) and the one that i erased is a cheap chinese clone of an stm32f103(also i cant find stm32f072 at a reasonable price). So there are two versions of the quicko t12 stm32 ,both of them report/ed HW:v3.1 and SW:7.1M, also have tried building the 103 version with the 072 .ioc , as the micro is the 103 but pcb layout is as on the quicko 072 but no luck, what should i do? thanks

Let me guess Jesus, Did you thought that by removing the read protection bits you could read it?
Yeah the ide doesn't allow quick mcu change. You have to make a new project selecting the new mcu, assign all the pins, the options, then copy all the source over it, being careful with common files like main and so, that should be done by hand copying the code.
Let me have a look at  it.
But I warn you, I don't know if it will work on clones (cks32 is a clone), it's been reported to have problems with spi.

[jesusvallejo]

i was looking at the programs associated with jlink on terminal and jlinkstm32 does that  , now i know that for sure hahah (dont play with terminals kids!!!), for the moment im trying to find legit stm32f072, but looks like its almost impossible do to covid , so i guess in the mean time ill try to port it and give feedback, the ide is kind like eclipse but at the same time isnt, also i dont know which files are propietary for the mcu model (stm32f072 only, like drivers i guess )and which arent.

[DavidAlfa]

All changes should be only needed in setup.h, main.c.
Of course it's not as simple as "I want this on the 103". But is much,much easier than changing the whole project.
In this case, the pwm output is timer4. In the 072, this pin is the TIM17 output. For the delay timer, I used TIM3.
So after configuring the timers correctly, I only had to change setup .h and set TIM3, TIM4, PWM_CH2 and set the "normal" CHx channel #define (this pin is CHxN output in the 072 ).
Change the adc device to hadc1... the spi is the same, hspi2...
The ADC has some differences in the rank channel configuration, so in this case I had to change some specific code in the adc functions.
I ordered few 103s almost a month ago, to play with them and start porting the fw to the ksgers. But still in transit... so stopped for now.
When they arrive,I will be able to make a proper code to automatically set the adc depending if using the 103 or 072.

This is a quick test. I can't test anything myself. I doubt the ADC works in the first try! But I hope that at least, the screen and the control work.
Don't connect the soldering tip at first! And if you do, connect it for just few seconds and check if it's heating.
The PID is called at the end of the ADC conversion, so in the case of the ADC not working,  the PWM should stay at the initial off state.
But don't trust anyone here. Test code can do anything! Turn off your wifi and hide your credit card too!

[tommi-muc]

Hi guys,

first of all let me wish you a happy new year. It is a very nice project which you've setup here. Thanks a lot for all the efforts you've spent so far!
I'm following the development with great interest and I'm reading the updates regularly. Now I would like to order a soldering station from Aliexpress as well but I'm a bit lost on all the available models and which one is supported or not. There are different MCUs available which differ in available memory...etc.
Which one would you recommend to order (also in terms of future development)?
Could it make sense to design a copy of the Chinese boards with some improved circuity for better performance or new features?

Cheers
Tommi

[jesusvallejo]

Working:
-Screen (Shows only "the soldering station")
-Piezo (beeps while tip is not conected)
Partially:
-Rotary encoder(pressing button while booting registers reset)
-Reset Menu (Screen glitches when "release button now" is shown )
Not working:
-Heat(tip does not heat up)
-Menu(not shown)

[DavidAlfa]

What's happenning? Freezes in the boot screen?
It's pretty much impossible to guess what's happening without being able to debug it.
Might be some code not correctly initializing a peripheral, or who knows...

Edit: I made a small mistake in the linker script that might cause memory overlap, so when the settings were stored, it actually could be erasing part of the program.
That migh explain the weird behavior. I replaced the file with the new one, try again...

[DavidAlfa]

Hi guys,

first of all let me wish you a happy new year. It is a very nice project which you've setup here. Thanks a lot for all the efforts you've spent so far!
I'm following the development with great interest and I'm reading the updates regularly. Now I would like to order a soldering station from Aliexpress as well but I'm a bit lost on all the available models and which one is supported or not. There are different MCUs available which differ in available memory...etc.
Which one would you recommend to order (also in terms of future development)?
Could it make sense to design a copy of the Chinese boards with some improved circuity for better performance or new features?

Cheers
Tommi

It's hard to tell. The ksgers are done in a very odd way, screen and memory are not connected to the spi peripherals and all the communication must be done in software, so forget  the speed for automated transfers using dma.
Quicko is what I have, and can talk about. Stock firmware is absolute crap, however the hardware is pretty decent and everything is correctly connected.
About the mcu power... there are few differences between the different stm32, however any is capable enough. Also easily replaceable if needed. Anyway, they change them on the fly to what they get cheaper. Today's and next week's models might have different stm32...
Designing  a custom hw would be nice, however there're already very nice projects, for example the Unisolder...

[jesusvallejo]

trying to see if pc gets stuck at a certain address but halt isnt halting the cpu(edit: didnt saw the update , uploading it to mcu)
Ok get the same behaviour, boots , shows "The soldering station" on screen all the time , if no tip is found beeps each second until its connectd.
if turned on while pressing encoder , shows "hold button to restore defaults" if keep holding, shows "release button now" but only updates the pixels used by the second message so the screen is a bit messy and then goes back to show "The soldering station". if tip is removed starts beeping again so it seems code is running.

Seems to halt always at  PC = 08002830 , CycleCnt is the only one that changes.

PC = 08002830, CycleCnt = 06901737
R0 = 20001208, R1 = 20000E9E, R2 = 00000000, R3 = 08002831
R4 = 20001208, R5 = 200012B4, R6 = 00000003, R7 = 00000004
R8 = 0000027F, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 20004E7B
SP(R13)= 20004F70, MSP= 20004F70, PSP= 00000000, R14(LR) = 080078D5
XPSR = 41000000: APSR = nZcvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00
FPU regs: FPU not enabled / not implemented on connected CPU.

[DavidAlfa]

Hmm... until I receive the 103s I'm out. Hopefully they will arrive soon.

[jesusvallejo]

its ok , no worries youve tryed and thats more than i can ask, ill wait until Correos delivers 

[DavidAlfa]

I can do barely nothing without debugging the hardware. The problem can be caused by a lot of sources.
Specially in the first build for a different hw.

Btw if someone has some graphics design skills, a new logo would be great...

[DavidAlfa]

I forgot I had a Bluepill lying around. Replaced the 072 with the 103 from the bluepill.
There was a nice bug! Somewhere in the widget processing functions, it could happen a situation where a null pointer was used.
Interestingly, when using the null (0) address as the widget typedef, the result was a call to the NMI handler.
In the 072 the NMI handler is non-blocking, just enters and exits, so I never noticed the problem, but in the 103 it's implemented using a a while(1) loop, so it gets trapped there forever.

Everything seems to be working. PWM, adc, encoder, screen...
There's still something weird going on, I can use compiler optimization for all  except one specific functions, doing so causes a hard fault.
Will have a look tomorrow...
Again, I replaced the file in the previous post, try and report.

[Bozog]

I forgot I had a Bluepill lying around. Replaced the 072 with the 103 from the bluepill.
There was a nice bug! Somewhere in the widget processing functions, it could happen a situation where a null pointer was used.
Interestingly, when using the null (0) address as the widget typedef, the result was a call to the NMI handler.
In the 072 the NMI handler is non-blocking, just enters and exits, so I never noticed the problem, but in the 103 it's implemented using a a while(1) loop, so it gets trapped there forever.

Everything seems to be working. PWM, adc, encoder, screen...
There's still something weird going on, I can use compiler optimization for all  except one specific functions, doing so causes a hard fault.
Will have a look tomorrow...
Again, I replaced the file in the previous post, try and report.

David I just tested your latest bin on github, it works 
Temp. readout is still a bit jumpy at 400°C but pretty stable at 340°C
Works fine tho, been using it to do some actual soldering today 

[DavidAlfa]

Nice! Well I wouldn't call jumpy +-3°C! Most stations just filter it and ignore small changes, so they will always show 360 as long the real temp is, for example, in a 15°C margin from the nominal temp.
I prefer to see the real temp!
The new mosfets arrived yesterday. Yay! I can play again!
My T245 shows amazing stability with 3mS delay. Below that it gets random +20ºC jumps.
I repeat again: Some tip profiles are waaay wrong.
Specially the DFLT. 3Kp 25Ki 0Kd! That makes the tip go crazy. When I set 45/5/20 the story changes a lot.(Edit: Much better with 35/10/15)

I'm currently redoing the method for targeting different boards.
Also merging I2C support.
I think is way easier now. Will update soon!
Edit:
This is the simplest approach I foun
We can't just use defines for everything, as the non-code related stuff can't be changed easily. And I hate when I see a new project and have to mess with the code to make it work!
It's not nice that you have to spend an hour to build something! So I decided to make it the simplest possible way. Copy,paste, few clicks and make.
The project config files are diferent for each MCU, otherwise you will have to mess with all the include paths, linker script and preprocessor defines.
As those files aren't code related, they will rarely need to be updated, so no worries about the manteinance.
In short, these are the files that each hardware template needs:
- CubeMX .ioc file: Hardware initialization. For configuring peripherals, GPIO, etc.
- .cproject, .project: Project configuration files.
- board.h: Specific board hardware configuration (this is the important file).
- stm32fxxx_it.c. IRQ interrupts routines, this file is generic, but is different for each family, and can't be mixed without causing errors. So we have 2 versions of the file,  for F0(stm32f0xx_it.c) and F1(stm32f1xx_it.c) families.
- startup_stm32xxxxxxx.s. This is the startup file very specific for each MCU. Automatically generated when creating the project but won't be regenerated if deleted. So we must save it. Can't be mixed with others.

So, for same MCU and different board, only  CubeMX (.ioc) and board.h files need to be changed.
And for new, different MCU, a new empty project has to be done setting the mcu parameters.
Then, copy the startup file, .cproject and .project files. And the board profile would be pertty much done.

So, now it's the time to try these KSGERS! We have a pretty stable fw with most issues solved! Any volunteers?

-

[jesusvallejo]

I did not saw the update, after some testing, some of the tips where at 300C when set to 200C , calibration sort of works still a bit of overshoot +20C(on external temp meter) o so, also takes a lot of time to go down in temp , up speed is very good.With my ILS tip gets sometimes a bit confused and temp on lcd suddenly jumps to 300 then goes to 180 when set to 200, with other tips works ok (all 5 of them are clones, not real hakko, the good ones are expected to arrive soon, will report then). The beeping all time while no tip is detected is a bit much in my opinion. very good job

edit: also when standby mode ,eventhough tip is off, says 64C dont know if its a limitation in the tip, mb we could change it to a big STB or something.

[DavidAlfa]

Hmm if I tell you the truth, I've never touched the buzzer. I removed it from mine the first day I got it.
Don't use the default  DFLT profile. Try B .
The DFLT is a total mess, makes any tip go crazy. I don't really understand why it's there.
Also the chinese tips are known to have such issues,  they usually settle after some "burning" time.
Yes, the sensor can't go lower than ~70°C. The thermocouple type is not usable below 100°C or so.
The temp can't go down by itself if the tip is hot and the heat has no go away. That is thermal mass "inertia".
Instead buying genuine hakko, I'd but the Jbc handle ($18 in AliExpress) and a genuine tip ($30, expensive as f** but worths it)

[jesusvallejo]

about jbc handle will do , i supose i will have to change the handle connector where may i find the schematics? , with b profile its dead on , 270 on set temp, and 270 on thermometer.

[cosmin1]

I'd but the Jbc handle ($18 in AliExpress)

That includes shipping? Where did you see it at this price?
They are all above 26$. Not to mention the C210 handle, with price starting from 35$.

[DavidAlfa]

16 euro / $19 with free shipping.

https://a.aliexpress.com/_BOuVGY

Don't buy the tips! They're trash!
Also you might need to fix the contacts, if they come too straight the cartridge doesn't insert smoothly.


So, I need a volunteer with a ksger board to start porting it! I need to know the exact pcb model.
The rest of ksgers are similar and shouldn't cause much hassle.

[cosmin1]

I tried on both these boards with f103 MCU. No graphics, no sound.
v3.1:

Ve2.1S r2:

[DavidAlfa]

No, the fw is not ready. I asked to know who could try the tests builds.
I have yet to adapt everything.

[TikhonovC]

I have the latest Russian Ksger (I bought it on November 11, 2020).
But I only used the firmware: 3.1Snew1.hex
I can check your firmware if you send a .hex file

[DavidAlfa]

Wait, soon I will start posting test builds. I'm working with software I2C routines so the Ksger boards work without modifying anything.