CFW for KSGER/Quicko STM32 Soldering Stations

[floobydust]

There is a strangeness with PB2 connected to GND on many versions of boards, that could be for the suicide feature...
I was putting together this I/O port assignment for the common boards. Almost the same for them.
Some boards use SPI, others I2C for the OLED. One board has the encoder pins reversed.

That pic looks wrong, OLED SDA going to pin 33 and MCU 15? OLED SCL going to pin 34 and MCU 14?

[cosmin1]

Have a look. Ensure your board and MCU are correct.
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER

Tested black pcb v3.0 with f103 and blue pcb v2.1s with f103 and right fw. None work.

OLED SDA going to pin 33 and MCU 15? OLED SCL going to pin 34 and MCU 14?

OLED SDA going to pin 33 and OLED SCL going to pin 34 on MCU.

[DavidAlfa]

No, that picture is a modification to connect the i2c lines to the i2c peripheral: That is not what I'm using on the builds.
Cosmin, I'm not a fortune teller... There are so many things that could be failing, without debugging is almost impossible to figure out.
If the schtematics are correct it should work... The only thing that occurs to me is if you are willing to let me debug it remotely, ex. using Teamviewer

[cosmin1]

It's fine with me. Can we do it now?

[DavidAlfa]

OK, I sent you a PM

[jesusvallejo]

so today i was testing a bit , and when load is big, a 100% is provided to the tip without limit and the tip got glowing red xd , tip is still working, i think the tip is now well "burned in". 
So to explain little furder , temp was set to 315 , big metal sheet, contact with leaded tin, power sets to 100% and temp on oled starts increasing , even if tip is not in contact(so no load) it keeps power at a 100% to the point it got glowing red. lowering temp sets power to 0%. So i think maybe we could add a limit, that can be bypassed or something so people dont kill their tips.

[dreamcat4]

big metal sheet, contact with leaded tin, power sets to 100% and temp on oled starts increasing , even if tip is not in contact(so no load) it keeps power at a 100% to the point it got glowing red. lowering temp sets power to 0%. So i think maybe we could add a limit, that can be bypassed or something so people dont kill their tips.

Hey there. I am just wondering if the big metal sheet was grounded, or connected to a path to ground? Because I have observed this phenomenon with my own thermocouple thermometer. The temperature does not rise hardly anything. And it messes up the whole thermocouple measurement. When the other thing you are touching with the thermocoouple is grounded. Or otherwise connected. Even if it is switched off at the time.

However it does not explain why the power kept going afterwards. Unless it got confused / stuck somewhow. And then continued to behave that way.

[jesusvallejo]

big metal sheet, contact with leaded tin, power sets to 100% and temp on oled starts increasing , even if tip is not in contact(so no load) it keeps power at a 100% to the point it got glowing red. lowering temp sets power to 0%. So i think maybe we could add a limit, that can be bypassed or something so people dont kill their tips.

Hey there. I am just wondering if the big metal sheet was grounded, or connected to a path to ground? Because I have observed this phenomenon with my own thermocouple thermometer. The temperature does not rise hardly anything. And it messes up the whole thermocouple measurement. When the other thing you are touching with the thermocoouple is grounded. Or otherwise connected. Even if it is switched off at the time.

However it does not explain why the power kept going afterwards. Unless it got confused / stuck somewhow. And then continued to behave that way.

No it was not connected to anything , i think i could replicate it with a big coin, i will try tomorrow and report back. edit: i have tryed again and achived the same glowing red tip.
even if the tip is no longer touching anything it keeps power at 100% achiving 450 - 500c (as per shown on oled)eventhough set to 315.

video: https://drive.google.com/file/d/1e66EGaBqzI_wBcZZfJvbUrg9o48N7iSw/view?usp=sharing

now station keeps going up no matter what , ive tryed other tips im going to try to reflash it.




BIG BUG!!!! with the lastest version in davidalfa repo when temp is set to 315 or above temp will go up without limit (will go glowing red). i have tryed 5 different tips, firmware compiled by myself , by david and happens all times if temp is set to 315 or above , the only way to solve it is to set temp below 315 as bug survived a reflash.

info about tested equipment:
bug:           315c and above power gets stuck at 100%
model:       quicko t12 stm32
mcu:          cks32f103c8(stm32f103c8 chinese knockoff)
firmware:    quicko stm32f103c8
fork:           deividAlfa/stm32_soldering_iron_controller
commit:      a108de3
iron profile: B
handle:       t12-9501(blue standard one)
tips:           ils,jl02,k0 ,bc1,bl

[floobydust]

In slow motion, you see the setpoint=325°C
Tip Temp:
running at 359°C PWM 100% 
climbs to 381°C PWM drops to 0%
drops to 371°C PWM 100%
climbs to 454°C PWM drops to 0%
drops to 428°C PWM 100%
climbs to 450°C PWM drops to 0%
drops to 426°C PWM 100%
climbs to 452°C PWM drops to 0%

It's 22°C jumps up and down.
If your measured tip temp is way above the setpoint, heat on and/or the P and D-term is positive, this is a fault condition, there should be no demand for heat - assuming the setpoint was not dialed down while the tip was hot, or going to sleep etc.
I would have a separate safety task that just looks if things makes sense or not. It can catch malfunctions. The PID algo seems to not be working.

[DavidAlfa]

When something like that happens, enter the first debug screen(long press on settings screen) and see what the pid is doing..
The error is the difference between the setpoint and the actual reading.
Once the temp goes over the setpoint, the error goes negative and the pid shuts down.
I have not noticed anything strange, I've been using it yesterday for hours at 380°C.
Hopefully we'll find the problem soon.

Also, if you're flashing it often with different versions, remember to force a factory reset..

[jesusvallejo]

yes i know in the video its set to 325 , the problems of live tv xd. Any how temp keeps scalating until you kill power, i mean if you are well above target why would you keep going 100% and only happens when im above 315c. will report back with a foto/video in debug mode. edit : as soon as i enter debug mode it goes back to the set temp. so i was wondering why it was red while set to 400c , it should not so i measured it and was at 600c xd , calibrated tip and testing does not seem to happen any more.

[DavidAlfa]

Hmm. After calibrating, what are the Cal values in the second debug screen? (Again, long press, but in the first debug screen)
If you make a factory reset, does it happen again?

[DavidAlfa]

I would have a separate safety task that just looks if things makes sense or not. It can catch malfunctions. The PID algo seems to not be working.

That is easy to say.. Add more functions, more checks ... but it's not that easy.
Maybe the internal PID is getting a wrong temp, or the PWM value is getting corrupted, or I wrong typed a variable name.
This is developing. Everything is often being modified and you can't check absolutely everything.
Specially now adding support for new boards, there were some big changes.
Yes, there are safety checks, but assuming the programs works.
If you copy a random value somewhere, that is a bug, and totally unpredictable.

For protection there's already the no iron detection and it works very well. Lower the limit to something you would consider a limit.
Set you iron to the max temp you wil use it, go to debug screen and take note of the ADC value. If it's ex. 3800, set the ADC limit a little higher, ex. 3900 o 4000.
So if the temp rises too much it will trigger the detection and force PWM to 0.1%. There's no way the PID works if the detectign is triggered, the PWM is always 0.1%.

What I don't understand is why it doesn't trigger the no iron detection.
Have you disabled it by setting it to 4100? That is ouside the ADC range and will never be detected. Max is 4095.

At first I deleted the problematic DFLT profile, but then I decided to reset everything to approximate values, with the idea in mind to calibrate your own.
All the calibration were wrong, some people even reported -100ºC. So there's no sense of storing these calibrated values.
This were the default profiles:

Code: [Select]


All by default (including DFLT):
calADC_At_200 = 1300;
calADC_At_300 = 2000;
calADC_At_400 = 3000;

"B  "
calADC_At_200 = 1221;
calADC_At_300 = 1904;
calADC_At_400 = 2586;

"BC2"
calADC_At_200 = 1463;
calADC_At_300 = 2313;
calADC_At_400 = 3162;

"D24"
calADC_At_200 = 900;
calADC_At_300 = 1932;
calADC_At_400 = 3598;

Now all by default:

Code: [Select]

calADC_At_200 = 1300;
calADC_At_300 = 2200;
calADC_At_400 = 3000;

Maybe I set some value wrong.
After successful calibration, let me know the cal values to note as reference!

My tip does:

Code: [Select]

CAL200:1468
CAL300:2373
CAL400:3379
Setpoint to 480:4000

So the detection is really close to limit on mine, but setting it to 4080 works.
Below that it triggers due the slight overshoot (reaches 4050 during 1/2 second when heating from cold).

As I say, I don't have T12 anymore, so I can't test it myself.
Also I won't spend money on something I don't need!
Maybe I should lower it even more, ex. 2500 at 400ºC

[jesusvallejo]

Hmm. After calibrating, what are the Cal values in the second debug screen? (Again, long press, but in the first debug screen)
If you make a factory reset, does it happen again?

Calibrated
Setp  c200    c300   c400
____|_____|_____|______
0      | 836   | 1327 |  1777

reset

Setp  c200    c300   c400
____|_____|_____|______
0      | 1300 | 2200 |  3000

After reset seems to work fine , no more scalating. Also i wont be using t12 soon, jbc handle is on its way , could you please point out how should  i solder the connector (pins on handle and pins on quicko)?

[DavidAlfa]

1770 for 400ºC?? That doesn't look fine! The TC is doing 14uV / ºC
T12 tips do around 21uV, so @400ºC it should be doing 2600ADC or so.
Unless your board has different amp gain... mine has 250. Ksgers usually 230.
So what to do.. I can't magically set calibration values for everyone! Buying a temp sensor will be mandatory.
Fortunately they're cheap.

Anyway I added another protection, a 5-level runaway detection.
It only works if the PWM is active, as logically the tip can't be heated if there's no output applied.
If the tip heats with no PWM, then your mosfet has blown and there's nothing we can do.

This is also needed to avoid false triggering when the iron enters sleep mode, or it goes from boost mode back to normal, as in that moment the requested temp changes to much lower than measured.

Difference 0-25ºC   : runaway level 0, not triggered
Difference 26-50C   : runaway level 1, 20 second timer
Difference 51-75ºC   : runaway level 2, 10 second timer
Difference 76-100ºC   : runaway level 3, 3 second timer
Difference >100ºC   : runaway level 4, 1 second timer

The values are  beta, I will probably lower them further.

So if the overrun condition doesn't dissappear in the specified time, the overrun protection triggers and halts everything.

Assuming there isn't an error somewhere that sets the PWM to 100% instead disabling it
Now I did something because everything works but the tip is not heating. Even the PWM shows 100%.
Or my mosfet died just now!
(Edit: dead cartridge)

[jesusvallejo]

changes by +20 depending on the tip, but i have tryed it with two different multimeters, with two different thermocuples i think its called in english and both say the same temp, how could i tell how much adc is doing, anyway it could be said in the readme that is highly recommended to calibrate if not mandatory.

[DavidAlfa]

It was one of my tips that died. My mistake, I forgot to turn off the station yesterday, it worked at 390ºC for > 18h. And had disabled sleep...
Also I think it suffered heatstroke, the debuger stopped while I thought I had disabled the breakpoints... I was checking the menu and suddenly it freezed.
After 3 seconds I resetted it and the temp was ouside the measurement range. Oops. But I think it didn't got red hot.
And no, there's nothing you can do to void this in debug mode. If you stop the processor, you stop the processor in the middle of whatever it was doing.

I've found that the runaway detection is a bit problematic when removing the tip.
Depending on what the amp does when the tip is not connected, there are situations that make the amp to read noise, but giving values below the no iron detection.
So the PID goes crazy oscillating between 0-100% on each cycle, and triggers the runaway. Adding the 1M resistor will probaby fix this, setting the amp input to a stable state.

For the rest of people, the worst that can happen will be the runaway error shown in screen and the station rebooting after 5 seconds.
I think there's nothing else I can do with this limited hardware. And I prefer safe than sorry. A few runaway errors from time to time are better than burned tips.
In my case, it only does that when the tip is half-way conected.
If it's totally in or out, it works well.
Code updated!

[floobydust]

Once your safety-check routine activates, I would also sound the beeper (as an alarm) so if I'm away from my bench, I know there is a danger- shorted mosfet etc.

Intermittent open thermocouple/heater is really a common problem with these T12 clone stations. Bad connections in the socket or cartridge. The hardware must default to something obvious, usually max. temperature and I add the 1MEG pullup. But we don't know if all the different op-amps behave the same (rail-rail) and can drive the A/D to 3.3V

I love Weller's approach to auto-shutoff and think it should be considered. Had a guy at work use a soldering station on the weekend and he forgot and left it running   Monday I looked and the tip was oxidized dead.
Weller's algorithm is based on sensing soldering-station demand.
If tip-temp never drops 3°C or more (wand sitting there in the stand, doing nothing), shut off the iron after X minutes.
Every time tip-temp drops 3°C or more, the shutoff timer gets reset because that is a tip getting cleaned or wiped, or being used to solder.

I never use stand-by mode because it only takes seconds to warm up from cold. I think it's silly and prefer the iron to just shutoff if not being used.

[DavidAlfa]

Well, that is something to have a look into.
3 °C is definitely not possible as the temp regulation doesn't have that much precision.
And if the pid is well done the temp shouldn't drop much.
In fact it barely does, unless soldering something big.
Soldering small parts doesn't lower the temp enough, you won't notice the station is off before 10 seconds or so.

If you see the power output, it's always using around 10% to hold the setpoint temperature.
And now, with the lower sampling rate of just 5Hz, the pid is more harsh, it will detect that the temp lowered n°C in 200mS and try to recover fast.
That doesn't cause any real trouble, but you can't rely on the pid ouput to recognize a small load. It will go between 0 and ~20% all the time.
If you get a big tip and solder a ground plane, then yes, the power reaches 50-60%.

But the idea is nice. I will try doing a mean of the last 100-200 pid outputs and see if the values are usable.
As I said, what worries me most is detecting the small loads. There's nothing more annoying that the station shutting off by itself while working.
Also, doesn't weller use induction heating?
It will have a lot of sensing circuitry.
We have almost nothing, just the pwm output and tc sensor.
The problem is just that I've fitted the Jbc handle and haven't wired a mercury switch or the signal to the handle stand.
So it never gets any sort of wake signal.

About the problematic cartridges, what can I do? Doing something in the fw will give a lot of headaches.
If you detect the temp going crazy up and down, halt the station? So now every time you change the tip it will also halt?
Also, that will make the bad tips impossible to fix by heating, as they usually fix themselves after some burn-in time.

[dreamcat4]

About the problematic cartridges, what can I do? Doing something in the fw will give a lot of headaches.
If you detect the temp going crazy up and down, halt the station? So now every time you change the tip it will also halt?
Also, that will make the bad tips impossible to fix by heating, as they usually fix themselves after some burn-in time.

Well if you can differentiate the situation for when the handle is not firmly contacting the tip. The metal rings....

Then you might occasionally flash up from time to time a simple message to the user like: "Check connection?"

To make them think to investigate more closely the handle. That it is keeping a solid connection. I think that could be very helpful.

However if you cannot distinguish the bad connection is inside and within the tip itself. Or the handle instead. Then it is really up to the user to check and dismiss the handle as the reason. But instead try with a different tip. And then notice it happening on tip A but not on tip B.

You see, i have kindda lost my trust in T12 tips and handles. After receiving the carbon fibre handle. Which is supposed to be the best T12 handle available right now. Yet despite being well made, and being electrically safe. Yet it still is not good enough? Because the hold on the tip is very loose. It spins and rotates freely in the handle. And the connection feels very loose. There is no click, or resistance when inserting the tip. It does not connect positively.

And yes... on the default chinese firmware the power flicks on - off - on - off. And it cannot stay on. So the overall heating is weak.

It's enough for me to say: well this handle requires modification. It needs to make a better connection electrically. With more force. More positively.

But for the firmware to notice this condition, (a regular disconnections of the TC). And to tell me with a warning message on the sccreen... well that would really be quite helpful. To be more sure, that I am not just imagining a problem. That it's real. And not due to something else. Or for other reasons.

[jesusvallejo]

regarding the handle on stand detection, on quicko station the rx pin on the swd header is connected to reset_state pa15 pin, having the tip conected to mains earth as it is on the t12 handle and connecting the stand to the rx pin, would make pretty straight forward to implement a similar solution as jbc(not implying that is easy , but very possible). also the sby detection works well with my iron , it turns off, and if no one touches the handle it stays off(forever), so i feel like its pretty redundant to have other ways that may take a lot of time to dev for very little results.


Also after trying last version pwm seems more linear and stable, dont know if you actually chaged anything regarding that but just saying good job!!
 im at an early stage but sort of works, set up pin as pull up , check in iron if pin == 0 standby mode, the next thing is to think if we want to standby as lon as is in contact with the stand or go to sby when briefly detects when leaving iron on stand.

example: https://drive.google.com/file/d/1eJWj2_00FMrCstD7iu6MOW7HMfQUTmVm/view?usp=sharing
Only on quicko , dont know if it could work on other boards, this is just a concept dont take it as "good" coding xd
.ioc
pa15 -> left click -> GPIO_input
pa15 -> right click -> Enter user label -> STAND_DETECT

main.c line 551

Code: [Select]

  /*Configure GPIO pin : STAND_DETECT */
  GPIO_InitStruct.Pin =  STAND_DETECT_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
  GPIO_InitStruct.Pull = GPIO_PULLUP;
  HAL_GPIO_Init(STAND_DETECT_GPIO_Port, &GPIO_InitStruct);

iron.c line 210

Code: [Select]


// Check if tip is in the stand
if(HAL_GPIO_ReadPin(STAND_DETECT_GPIO_Port, STAND_DETECT_Pin)==0 ){
if(Iron.CurrentMode != mode_standby){
setCurrentMode(mode_standby);
}
}
else{
setCurrentMode(mode_normal);
}


[DavidAlfa]

Yes, the stand detection is the easiest to do!
No worries, just check if it's 1 or 0, and go to standby or wake up.
It's faily easy, also if you set the GPIO with the weak pullup, you won't require any additional resistor.
But for safety, better to add a series resistor like 10K and a few nF cap to filter possible voltage spikes.
I would like the rest was so simple! 
I wpudl like to add a tons of new menus for all that. But the menu system it's done in a way that makes it messy.
You can have scrolling titles, but no options. So you must do a new screen for the options, and only the few that fit in the display.
The menu requires a whole recoding to allow that. Then the options will be much nicer, and easier to add.
That's why the buzzer is set in code but not in the menu. I don't want do add a thousand screens!
My idea is to add just a few menus, then each with all the options in scrolling.

And, nope, I don't remember changing anything in the PWM or PID.
I added the runaway detection, improved some internal functions and I reduced the default calibration values to much lower.

[jesusvallejo]

After close inspection of the settings screen code i thin the problem is that the "options" are declared as widgets instead of comboadditem as in the menu, probably because its the only way to add an option box or what ever , documentation about microgui is not very extense, im trying to find if there is a way.I think what you meant was that having a menu for each option in each menu is a bit too much and you are right. if you have any id4ea how to refactor it im available to help   

[dreamcat4]

OK... have now updated my research docs, for those sections which talk about how to backup the original firmware. Since August 2020, there is now a much easier power glitching attack, to unlock the protected flash memory.

It only requires an STM32F3 development board. And not a lot of skill or anything particularly challenging. If anybody is interested, you can read more about it here:

https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/tools/software/STM32CubeIDE#option-2-power-glitching-timing-attack

Not sure where those boards are available from. Probably: Farnell, Digikey, and similar. But I would expect them to be fairly cheap and inexpensive?

[EDIT] yeah... search for "STM32F303VC" dev boards or "STM32F3DISCOVERY". They are pretty affordable. Under $20 on mouser or digikey:

https://www.mouser.co.uk/ProductDetail/STMicroelectronics/STM32F3DISCOVERY/?qs=%2Fha2pyFaduhRYzl9i01%252Bk0RzdRIzmgXiQMqh5UXh85Q1TO9QNL%2F%252BiQ%3D%3D

https://www.digikey.co.uk/product-detail/en/stmicroelectronics/STM32F3DISCOVERY/497-13192-ND/3522185

Seems to be more expensive from other places. Farnell / CPC is more like $23.

https://uk.farnell.com/stmicroelectronics/stm32f3discovery/evaluation-f3-cortex-m4-discovery/dp/2215108?ost=stm32f3discovery

[DavidAlfa]

After close inspection of the settings screen code i thin the problem is that the "options" are declared as widgets instead of comboadditem as in the menu, probably because its the only way to add an option box or what ever , documentation about microgui is not very extense, im trying to find if there is a way.I think what you meant was that having a menu for each option in each menu is a bit too much and you are right. if you have any id4ea how to refactor it im available to help   

The widgets and combobox are nothing from uGUI. That was done from scratch by PTDreamer.
uGUI only places lines, squares, and text.
There's absolute no documentation, I had to figure all myself!

Combo items only allows labels, not widgets.
The widgets are dynamic objects, the position can be relocated dynamically, also disable or enable them.
But there's no actual method to add them to a scrolling list.

I'm working on modifying the ComboBox widget, to allow two modes:
- Screen: The classic, text label, clicking enters a new screen.
- Option: Label, and a widget pointer. The widget will be drawn next to to the label.
              Instead selecting the label, it selects the widgets. And clicking edits the widget.

Is no way so easy but I hope to get something.

It only requires an STM32F3 development board.

Interesting finding! If that lets the user backup their original fw for testing 3rd party ones, great!
Is the STM32F303 needed? Specifically? Can't be done with other stm32?