CFW for KSGER/Quicko STM32 Soldering Stations

[DavidAlfa]

Go to settings, system and adjust offset to 0.
Some display have different offsets, by default I set it to 2 because that is what my display use.

[dreamcat4]

Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.

Is this with i2c bus? Could it be same problem as this other guy found?

https://www.programmersought.com/article/71326761904/

It was with spi but I think it's dma related, not spi .
Anyways if checking by that it works, it's done.
Edit: Only checking the DMA didn't fix it. Got few crashes.
Reverted the fix to the previous one.

If it is SPI then maybe it's on page 28 of the errata then? (image 1) Or it could be a conflict, when multiple IO devices are used together, in a specific combination (image 2)

[DavidAlfa]

I don't see relation...
SPI is not used with CRC enabled. That is usually used for SD cards (Frames are ended with CRC checksum).
Neither do I2C and SPI coexist. One of them is totally disabled.
I don't know if it happens in I2C mode. I only had that problem in my boards (And Jesus's), using SPI.
Definitely there are no more crashes, running for 3 days now without any issues. So I wouldn't bother.

[thebao0273]

Hi, a weak ago the firmware work well with me but days ago i saw you update the code so i flash my board with \KSGER\[v3.1]\[64pin]\STM32F101RB and nothing boot up i think u just change the pin  the oled is PB 13, 15 OLED_SDA, OLED_SCL (schematic) to SPI2_MOSI, SPI2_SCK. Maybe this cause my board don't work? Sorry i don't have knowledge about stm32.

[DavidAlfa]

Let me check it.
These names don't matter if using spi/i2c in hardware mode. Only used in software mode.

[TikhonovC]

Hi, will STM32F101RB firmware work for STM32F101RC ?

[jesusvallejo]

Hi, will STM32F101RB firmware work for STM32F101RC ?

is it the same board, if so yes if not no

Also oled does not work on last version in github quicko f072 with provided bin neither with compiled,still have to test f103.

[DavidAlfa]

I have to discard possible display compatibility issues from the latest changes. Also I had placed some preprocessor #ifs incorrectly.
Jesus, please try these.  My 072 board is currently removed and the display desoldered, so I can't test it. My 103 works nice.

[DavidAlfa]

Hi, will STM32F101RB firmware work for STM32F101RC ?

Yes, using the same family but bigger memory variant should work just fine.

[jesusvallejo]

I have to discard possible display compatibility issues from the latest changes. Also I had placed some preprocessor #ifs incorrectly.
Jesus, please try these.  My 072 board is currently removed and the display desoldered, so I can't test it. My 103 works nice.

none of them work xd , the provided bin in this commit does:
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/353a33fa8c2028d5d089bec4cbf956efd5a71cf0 but seems its even older,as its 6 days old

f103 works perfectly as you said. Also the encoder is super good(va fino fino).

[DavidAlfa]

What the... 

For the Ksgers: From now only the STM32F101 will be built. It will also work in 102 and 103 (but all running at 36MHz).
I can't lose so much time updating everything everytime while there's no real difference in performance

I uploaded new builds. Didn't see any problem really. Litte comestic bugs in the error screen, nothing else.
Stm072 works fine for me! (Yes, broken screen) Flashed exactly the same binary from github.


Edit: Nice that it goes "fino, fino" 

[jesusvallejo]

now works with the last pull i have tryed also in windows and cant get it to work  , ont know what could be happening 

There might be a bug regarding the stand(just fyi i replaced the resistor so the tip is grounded), the stand is correctly detected but if i boot with the tip touching the stand sleep mpde is not triggered until i get the iron and place it again in the stand.Also tip type selection is missing ajajajaj

also it is not a problem for me if you dont provide bins for the quicko if it saves you time, or if you want to stick to f103 or f072 as i have spare of both and can solder either.

[mikes]

@DAvidAlfa, thank you very much for all the work you are doing. It is much better than the original code.

The edit tips menu is not only the name... each tip have its own pid data, max power...
The specific tip pid settings are loaded when you change it, and pid control uses that data.
Then each specific profile (T12, C245, C210), has its own pwm settings, adc delay and few others.

I suggest that when creating a new tip, tip info (calibration, PID, power, etc.) should be copied from the first tip (e.g. "DFLT"). That lets you make settings once for DFLT, then just make small changes when adding new tips.

Now the main task would be to collect calibration results from different boards and set them as base into the firmware.
So anyone could use the firmware without huge temperature differences if not calibrated.

I just loaded the latest .bin (r2135e11) on my KSGER OLED-3.0 (103RC). When calibrating (T12 tips), these were the readings I got 130@200, 219@300, 288@400. 

One problem - when set to use Fahrenheit, the calibration doesn't work correctly. It will show "CAL STEP: 200", then "WAIT... " with the temperature in F (but shown as C!). i.e. if I set the temp to 390F, then go into calibration, it will show "WAIT... 390C", and waits until the tip drops to 200F (displays 200C). But the tip is actually cold then. It is probably easier to just try it yourself than to understand my explanation.

[mastershake]

my stlink may have an issue i tested it on something else and i had a simiar issue to the ksger f102 so i ordered in a few new ones should be here early next week sorry for the delay

[DavidAlfa]

Calibration -must- be done in Celsius, the fw works in that unit  internally. Farenheit support is done by converting that.
I see that I forget to force the system to use Celsius when entering calibration screen, and restoring it back when exiting.
That happens when F is not your everyday unit. Farenheit mode is no extensively tested.
Fixing that soon. About the tips, not a bad idea. I will have a look at that.

Your build is already old! Try the latest (r52bc1a1) and confirm that it's working 

[DavidAlfa]

What are the exact issues? Most have easy solution.
The usual issue is when you flash a corrupted fw or one that doesn't have SWD enabled.
After that, stlink won't be able to flash it again without connecting NRST.
You can still fix it easily by shorting the reset cap with the tweezers, then clicking Erase command, and releasing the tweezers 1 second later.
The timing need some practice. Or just solder a wire to NRST.

[DavidAlfa]

also it is not a problem for me if you dont provide bins for the quicko if it saves you time, or if you want to stick to f103 or f072 as i have spare of both and can solder either.

Oh the quickos are just 2 versions with very different processors.
The problem comes with the ksgers. For only 2 boards, already 5 builds.
Mostly the same (101,102,103) but it's a tedious process to repeat the same thing everytime.
And since the 101 works in 102/103, why bother so much

[mastershake]

just blank screen. i have flashed stm32 before so i dont think im doing it wrong. it looked like it finished and everything went fine but no power after just appears to be dead.  this stlinkv2 i opened and the soldering is total crap and it has a cks chip on board it was given to me so who knows. i went ahead and ordered a pair this seller swears these should work fine they have great reviews. for the few bucks no sense in beating around id rather start with a new one. 

i was going to go ahead and solder on a new chip to this board. ill try the erase first when the new stlink's arrive before doing that, i do have a few spare stm's here now though if need be. looks like tues according to the tracking number.

[mikes]

Your build is already old! Try the latest (r52bc1a1) and confirm that it's working 

Oops, that doesn't work. It just flashes the splash screen (constant reboots?)

Using the file here: https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/%5Bv3.1%5D/%5B64pin%5D/STM32SolderingStation.bin

Code: [Select]

Memory programmed in 4s and 680ms.
 Verification...OK
 Programmed memory Checksum: 0x004D2FBE
Went back to r2674313 (which I had a copy of), back to normal.

[DavidAlfa]

Yeah my stlink came like that. Bent pins, floating on top of the solder. But I gave it some love with flux and it's working nicely.
If it verifies correctly, then it should be working. Otherwise it should give some error.

[DavidAlfa]

Your build is already old! Try the latest (r52bc1a1) and confirm that it's working 

Oops, that doesn't work. It just flashes the splash screen (constant reboots?)

Using the file here: https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/%5Bv3.1%5D/%5B64pin%5D/STM32SolderingStation.bin

Went back to r2674313 (which I had a copy of), back to normal.

Actually the default calibration values are set very low intentionally to avoid burning the tips.
I don't have those boards, I can't test them, so, as I always say, I  prefer to be safe than sorry.

The measured temp is not what I need for the calibration, I need the ADC reading.
I modified the calibration screen to show these values after a successful calibration.
With those I can set a default calibration for each board.

About the bootloop, I already knew it existed. It didn't happen often, and when it did so, it was always after a flashing procedure, so I blamed the flashing...
But I found the issue. It  happens when the system settings changes (when new settings are added), or the checksum fails.
The system settings were loaded, checked, resetted and saved before loading the profile data. But all must be saved together.
So the system profile was empty in that moment. Storing the settings would also store that empty profile, computing a correct checksum.
After that, it would bypass all checks, causing a bootloop. The main issue was loading the PWM with 0 data.
That breaks the pwm, the system watchdog stops updating and resets the system. Good boy doing its work 

All that should be fine now. Calibration screen is fixed. And new tip data copies the data from the first tip.
Will upload the code and the new builds in a moment.

[mikes]

I'm almost done fixing the calibration and copying the tip data for new tips.
Also, the measured temp is not usefull here. I need the ADC reading for puttong that into the database, so i can set the most accurate calibration by default.
I modified the calibration screen to show these values after a successful calibration.

Resetting to default fixed the reboots. Thanks.

I can provide the cal data, I'm assuming it will be shown in a future version, r52bc1a1 doesn't show it. In a previous post you mentioned deliberately making the default low, I agree. I don't know how much variability there is with these, but ~20C low seems reasonable. I'm seeing 100C low now.

Another suggestion: when doing a calibration, start with the defaults. Right now, it seems to start with the existing calibration. I recalibrated a tip, and ran into an issue where it couldn't reach what it thought was 400C, so ended up with a "red" tip. I had to delete the tip and recreate it.

Also, some tips will heat up, show "NO IRON", recover a few seconds later and repeat for a while until settling down. I seem to be able to fix that by setting "Iron/No iron" to 4100 (from default 4000). Perhaps it should be allowed to be set even higher?

Finally, and this is NOT important, just cosmetic. Menus say "BACK" except SYSTEM, which says "RETURN". You can save a couple of bytes and make it consistent.

[DavidAlfa]

Correct, I forgot about that issue, it happened to Jesus.
As you can't reset that, after some wrong calibrations you end with too high values that migh be impossible to reach. I will set always a default value.

About the no iron error: It's a tip fault, very common. Something's wrong inside the TC sensor.
Some people say it's moisture, while others think it's a poor internal connection.
I had issue that with most T12 tips. Leave it running at 400ºC... it usually settles after a while.

The ADC can measure between 0 and 4095, being 4095 is the max supply voltage (3.3V).
Anything over that will totally disable iron detection. That's why the 4100 is there.
If the ADC reads so high, it's because the circuit is open or not working correctly.

I decided to delete the T12 tips. Leave only one with the default profile.
These calibrations are not valid, as each board has different variations.

[mikes]

Ah, I didn't know what the "No iron" value directly represented. Odd that it will still detect NO IRON when set to 4100 - although it takes a few seconds (can EMA/DEMA overshoot?). I'll try setting it a bit lower.

Thank you again for all your work. It is appreciated, and you're doing good work. I've done projects for myself, just for the satisfaction and learning, but without much interest from others. I understand how and why you'd want to simply stop when it's working for you. I hope you stick with it for a bit more, you've added a lot of value and improvements to what we started with.

BTW, the board I have is marked OLED-3.0. I think it's electrically identical to a 3.1 board (I have one of those, too), but they moved the pads for the on-board battery and the off-board battery connector.

One other thing I've noticed - the button doesn't always work in the menus. When that happens, it simply stops working (I can press multiple times, hold it, etc., nothing) until I scroll up/down, then it works.

[DavidAlfa]

If you set it to 4100 and no iron is still there, check the ambient temperature.
KSGERs usualy have the ambient sensor in the the handle.
If unconnected, the ambient temperature reading will be below -60ºC. That also triggers the detection.

With the default 200mS PWM, the tip only gets updated 5 times per second. Setting a high EMA/DEMA factor will make the filtering response very slow.
Leave it in AVG by default. Set the temperature and play with settings until there are no spikes or anything weird.
Then you might try the other filters.

EMA causes delay at the filter output, and will cause PID overshoot.
If done correctly this can be beneficial, to compensate  the tip thermal mass (Heat doesn't travel instantly from the heater to the tip),making it to heat faster without real overshoot.
However, when the tip gets cold, it also causes delay so the PID will not react so fast.

DEMA also has delay, but will react faster to the changes.
It will stop the PID faster when it reaches the temp, but also when the tip loses heat.

Check this picture (Blue line: original signal, orange line: regular EMA, red line: DEMA.):


As you see, this can affect the PID a lot. Must be carefully tested, it can cause serious oscillations.
I wouldn't use it with a factor higher than 2 by default.

Also, did you play with the ADC delay? Setting it too low will cause a lot of trouble, false readings and such.
If you lower too much, the ADC will be reading the voltage spikes after turning off the heater.
By default is set to 200mS PWM, 20mS delay, it was the most stable, safe and efficient.

Builds updated!
No more random bootloops when the settings version changes.
Calibration should be doing well now. Also the ADC values are shown when successful.
Added more checks to ensure the calibration values never get higher than the ADC range, otherwise set the calibration failed.
Hopefully this was the last issue with red hot tips. The only red hot things I like are the chili peppers