CFW for KSGER/Quicko STM32 Soldering Stations

[DavidAlfa]

Well, I got it!
The whole menu is renewed.
Now the menus can be extended easily, and the initialization is way easier.
And as the combo box was modified intentionally this way, regular labels and editable entries can be used together, the first are used to enter a new screen, the second are attached to a widget and automatically takes care of everything, even placing it in the same height as the label it was attached to.
And I replaced the ugly square  boxes with rounded ones, they look so much nicer.

Added few more options that I had in mind but couldn't due the menu system limitations.
And there's still plenty of ram free!
Video:




Yes, I'm again without iron tips...

[jesusvallejo]

so cool , cant wait to upgrade
Problem in line 590 main.c ironwake() takes a bool as argument but none is provided on that line. just set it as 1 , working as expected.Also there is no longer wave widget when motion is detected on handle.

[DavidAlfa]

I don't know, probably you catched some transition code. There were a lot of changes, so I had to update the repository few times in between. I've compiled the boards a moment ago and all did perfect.

Git code updated, also the test binaries.
Had to set the NTC temp table as board specific adjustment. KSGERs use 4K7 pullup, while Quickos uses 10K, so the NTC reading  on the KSGERs was totally off.

Changed the ADC trigering by Timer TRGO signal to manually start it from Timer interrupt.
This allows the use of any timer, as I discovered that not all TRGO signals can be used to trigger the ADC. This was a problem on KSGERs.

Hopefully should work on  KSGERs now.

As the system configuration now has more settings, I changed settings versions to v11 to force resetting to defaults after firmware upgrade.

Jesus, try it out!
Cosmin you too, and report if the ambient temperature is correct now.

I've just removed JBC option and added C245 and C210 . C245 uses the same values as C210, it's not calibrated.
It's safe, as the C245 outputs much high voltage that the C210, so the real temp will be much lower.
Unless you give me away C245 and C210 tips, I won't buy them to calibrate anything, try yourself and report calibration values!
This last change is not yet in the compiled bins (I need some time for myself! )

[jesusvallejo]

will report back , also dont know if its against the rules of forum but if you post paypal i will send you a couple of beers , fantas or coffees. 
ok its working fine, the new gui is far better, also what does it mean Enc. Wake?

[DavidAlfa]

Encoder wake. So the iron also wakes up on encoder activity.
(Edit: Changed to "Button Wake" as it fits perfectly)

Ah, also the Iron mode times (Boost, sleep, standby) were changed to minutes.
No sense adjusting seconds in that.

At last, I found the weird bug that made some widgets to change its value a somewhat randomly when moving the encoder fast.
This happened where bigs steps were used, like PID and ADC limit widgets.

Now there's only a small bug left on the dot insert  that makes numbers >99x9 shown a as 1000.x. Not a problem else than weird displaying.

[Il_Marco]

Really nice work DavidAlfa, I like new menu and I'm really looking forward to trying you last CFW as soon as I get my spare STMs. Really many Thanks to everyone helping here!

[DavidAlfa]

Still have to do something with the widgets.
Although now I use less than ever, still each one takes 120bytes of ram for... a button? A 3 character  value?
There're currently 66 widgets so... I have to find a way to enhace that.

[totalnoob]

Sounds like things have been progressing very well on the CFW front.  One question, do you still lose the settings from one handle if you were to switch to another (say from T12 to using a C245) or can you now keep the settings from the previous handle from being overwritten when changing to another?

[DavidAlfa]

I've been working on that for a while already.
Hopefully, soon.

Edit: Almost working. That was a big pain to do... had to rework a lot of code!
Each iron type profile uses its own times and temperatures(standby, sleep, normal, boost), adc, pwm, etc settings.
Because , for example, T12 seems to need much higher recover time than C245. So it's better to isolate these settings.

To allow easy recover from messing something up, I also implemented new reset settings: only system settings, only current tip data(T12, C245, C210), all tip data(everything), or total reset.

[Grossmeister]

What version of T12 hardware one should buy to be able to upload this custom firmware into STM32 controller and what external hardware will be necessary for this?

Also, I personally like the idea of having STC controller and 7-segment screen module with an "advanced" firmware. I'm pretty sure it can handle a minimal set of advanced features like: sleep  time, sleep temp, power off time, encoder temperature step, individual calibration of 3-5 tips (who uses more?). Another nice thing that it can be programmed using a simple USB adapter.
Is there any detailed information about existing STC firmwares: firmware backup that can be used to restore controller after playing with it, etc.?

[jesusvallejo]

for the time being , quicko t12 stm32(so my first buy came with a stm32f072 about 3 months ago , and the second one with a cks32f103 about a month or so ago,both versions supported, as the pcb is exactly the same but the mcu), ksger v2.1s(64 pin both stm32f101 and stm32f103 ), v3.1 (64pin both stm32f101 and stm32f103), i would ask for a foto of the pcb or something before buying and check with the photos in documentation as if you buy something already working you dont have to rely on someone like david to port it as looks like they change hardware pretty easily and it takes time to adjust it.Also you will need an st-link or similar to flash it.
Regarding 7 segment , its possible yes , is someone in here willing to do it , dont think so as the developement requires having the device(maybe if you buy it for the dev, dont know).
And the usb adapter, no(depends , F103 does not have a built-in USB bootloader. Bootloader in F105, 107 has the USB option. for example ), i suppose you can update stm32 via usb but the mcu pins are pretty small and unused pins do not have a header, not accounting on someone having to research how to do it on multiple devices, no where to place the connector etc. a lot of work when swd is simple and dirt cheap.




on another topic:

the power glitching attack: so after having a look at it the main problem is the STM32F3 has 32 bit word(works with thumb 32),stm32f103 does too !!, it is implemented in assembly , and while pretty basic having it to work with different mcu is a bit too much as the register address for gpio and different states change from mcu to mcu. i bought a blue pill to see if i can port it as i don have any board to do so. so my idea is the attacker would need a blue pill, an swd(st-link v2 for example), and a usb2serial converter,probably a lot of people in here have both 3 or at least 2 so should be pretty cost effective. i found the STM32F3 for 16 euros on farnell so, in case you dont have a stlink and a serial2usb mb its a neater solution to have it on one board, anyway ill try to port it to the blue pill, ive managed to get working the leds using qemu emulator, but cant emulate buttons so im stuck until i receive the board.

[DavidAlfa]

What version of T12 hardware one should buy to be able to upload this custom firmware into STM32 controller and what external hardware will be necessary for this?

Also, I personally like the idea of having STC controller and 7-segment screen module with an "advanced" firmware. I'm pretty sure it can handle a minimal set of advanced features like: sleep  time, sleep temp, power off time, encoder temperature step, individual calibration of 3-5 tips (who uses more?). Another nice thing that it can be programmed using a simple USB adapter.
Is there any detailed information about existing STC firmwares: firmware backup that can be used to restore controller after playing with it, etc.?

Of course, alternative firmwares are great!
I'm already crazy busy with the STM32 project, taking the 99.999% of its development.
Not being a professional coder (Although I must admit, my skills improved a lot with this project), developing it lot takes of tries, failures and debugging hours.

I won't take the huge task of porting to a new device that:

(A) - I don't known, mostly only chinese use them, so why taking the huge task of learning it?
(B) - I don't have, I don't need.. and I don't want even free. It's just a calculator that heats up!
(C) - Has documentation in chinese! Most development is also in chinese. Get prepared  to find specifications, examples and forum support.
(D) - Already works pretty well, what can else can you expect from a 7-seg display? I don't expect any fancy features on such device.

[DavidAlfa]

(...) F103 does not have a built-in USB bootloader. Bootloader in F105, 107 has the USB option. for example ), i suppose you can update stm32 via usb but the mcu pins are pretty small

Anyway, the built-in uart bootloader works great, almost the same as by usb, you only need a cheap usb-serial ttl converter and the flash loader demonstrator.

Oh my, I started to see Hard faults everywhere... I even think I dreamed with a few!  .
On first try I didn't think it enough, had to revert everything and start again using a different approach. Buuut it's done!
New profile system, now easily expandable, so in the future I can add support for new profiles in a breeze.
Included by default T12, C210 and C245. None gets deleted unless the user erases it.

Also, each stored data uses its own checksum, so in case of error only that slot is erased. Like this:
[SYSTEM SETTINGS][CHECKSUM]
[PROFILE1][CHECKSUM]
[PROFILE2][CHECKSUM]
[PROFILE3][CHECKSUM]


"Iron Type" menu and warnings are gone! Don't blame me if you mess up setting the wrong profile for the tip, be careful!
(I'm still thinking on detection method that doesn't need hardware modding)
The profiles can be changed on the fly from the Settings/SYSTEM entry. (Profile setting)

A new check after the boot splash is added, to detect first booting after a clean flash, that will prompt the user to select the correct profile.
Pretty similar to the old iron tip screen.


I discovered that CubeMX was allocating a lot of heap. Reduced it to almost 0. It freed up additional 1.5KB RAM. As I don't use dynamic allocation, it's ok.
(that was one of the big issues in the original fw, uncontrollled ram usage, hard faults everywhere...)

New settings use 2KB flash. Only the active profile is loaded to ram to save resources.
64KB devices are starting to struggle at 92% but still holding well!

The binaries are updated. As always, force reset at boot.

Also, as the state is stored, when you returned to a menu it would always be in "exit" or "back" modes(last state before exiting the menu), something I always found to be very annoying.
I made some changes in the screen system so there's always a "lastscreen" variable, very useful for taking certain actions depending on the screen you came from.
I use that to reset each menu to initial positions unless coming from a submenu.

[jesusvallejo]

nice i will try it , the power attack should be ready i cant try it until my blue pill arrives but it should be working, ive checked every single address and seem ok , its pretty much the same code but the address for the gpio moved from gpiod to gpiob and gpioe to gpioc https://github.com/jesusvallejo/BluePillPowerAttack

[Grossmeister]

I won't take the huge task of porting to a new device that:
(A) - I don't known, mostly only chinese use them, so why taking the huge task of learning it?
(B) - I don't have, I don't need.. and I don't want even free. It's just a calculator that heats up!
(C) - Has documentation in chinese! Most development is also in chinese. Get prepared  to find specifications, examples and forum support.

Is this about STC controller? Do I understand correctly that the main advantage of STM32 over STC is not calculation power, but 1) better development environment and 2) much better documentation? If so, then yes, STC becomes a bad choice for custom firmware.

What would make this project really useful is coupling it with a reference schematics, so people can assemble own board without a need to fight with Chinese sellers for a correct PCB version. Something like this: https://www.electronoobs.com/eng_arduino_tut49.php

[jesusvallejo]

after trying i get error while writing to flash! no matter if flash the provided or compiled. Also cant force reset at boot.

[DavidAlfa]

Hmm weird... I'll have a look. If I can't find anything will you let me debug yours with TeamViewer?

[jesusvallejo]

ive got it set up on linux, if we can do it there or you give me time to install whats required on windows yes,  also older commits still work

ive tryed flashing it on windows and let me select the tip but still same error after that, also i have every thing ready on windows so if you need to connect just let me know
 mb has something to do with

implicit declaration of function 'memcpy' [-Wimplicit-function-declaration]   settings.c   /STM32SolderingStation/Core/Src   line 46   C/C++ Problem

[DavidAlfa]

I've been working on modifying the widgets system to free even more ram while allowing dynamic data length.
Now all uses pointers instead a fixed data array for every widget.
When I finish that, l'll look at the rest of the builds. The problem will probably be a minor bug, like a typo or something like that, or wrong linker settings.
Should be easy to find, as it doesn't fail on mine, smeels like a profile-specific setting.
Edit: Done. Almost 3KB RAM gained! 16KB devices still have ~3.8KB left. The widgets still use a lot of memory, but it's something.

Edit2: Had a quick look and the problem was pretty obvious.
Flash page size differ between the different stm32 models. Some use 1KB(F103xB/8, F101xB/8), others 2KB(072xB).
Added a check  to erase the correct ammount of flash pages. Easy fix.
My checking routines did the correct job ensuring the stored data was correct , stopping the black hole happening! 

Code and builds updated! Let me know how the new edit mode looks, I think the readibility is far better than with the "inverted" look.

[jesusvallejo]

I've been working on modifying the widgets system to free even more ram while allowing dynamic data length.
Now all uses pointers instead a fixed data array for every widget.
When I finish that, l'll look at the rest of the builds. The problem will probably be a minor bug, like a typo or something like that, or wrong linker settings.
Should be easy to find, as it doesn't fail on mine, smeels like a profile-specific setting.
Edit: Done. Almost 3KB RAM gained! 16KB devices still have ~3.8KB left. The widgets still use a lot of memory, but it's something.

Edit2: Had a quick look and the problem was pretty obvious.
Flash page size differ between the different stm32 models. Some use 1KB(F103xC, F101), others 2KB.
Added a check  to erase the correct ammount of flash pages. Easy fix.
My checking routines did the correct job ensuring the stored data was correct , stopping the black hole happening! 

Code and builds updated! Let me know how the new edit mode looks, I think the readibility is far better than with the "inverted" look.

edit: gui is now working but th te tip does not get hot, adc 34  p = 31 i =6  d = 0  err =708 out =0,also pcb temp says 30c and it isnt . Also gui is far more readable now, good job.
 

[DavidAlfa]

Did you made a full reset?
I have the 072 quicko station, and an additional quicko board that got as warranty replacement back then, I put 103 in that one.
They differ 2ºC in the ambient temperature right now. The board inside the enclosure is hotter from being in a closed space and also the power supply heat...
I can't try the pwm (dead tips,again)

Edit: Humm, yes something happened. It's not loading something. Power always shows 0%
Once you select each profile, and go back to the settings menu, it works again. And will work unless you reset everything.
Another bug! You know, for each feature you ad 2 new bugs haha.
Edit Fixed: The programmer  The ape changed a profile variable after computing the checksum, when the checksum should be the last operation.
Also ensured to align the data to 32-bit , as the CRC uses that word size.
Thas wasn't the problem, however that is undefined behaviour and could catch some random data at the end if not computing an exact multiple of 32 bit data.

Builds updated

[jesusvallejo]

Did you made a full reset?
I have the 072 quicko station, and an additional quicko board that got as warranty replacement back then, I put 103 in that one.
They differ 2ºC in the ambient temperature right now. The board inside the enclosure is hotter from being in a closed space and also the power supply heat...
I can't try the pwm (dead tips,again)

Edit: Humm, yes something happened. It's not loading something. Power always shows 0%
Once you select each profile, and go back to the settings menu, it works again. And will work unless you reset everything.
Another bug! You know, for each feature you ad 2 new bugs haha.
Edit Fixed: The programmer changed a profile variable after computing the checksum, when the checksum should be the last operation.
Also ensured to align the data to 32-bit , as the CRC uses that word size.
Thas wasn't the problem, however that is undefined behaviour and could catch some random data at the end if not computing an exact multiple of 32 bit data.

Builds updated

yes full reset was made, in my case pwm shows 100% no heating, with older firmwares works, so its not a dead tip or or component.

[DavidAlfa]

Yes I know, it was a security feature not being disabled after the boot screen. All that is fixed. Or should be.
Unless something messed up with the pwm pun configuration

[jesusvallejo]

Yes I know, it was a security feature not being disabled after the boot screen. All that is fixed. Or should be.
Unless something messed up with the pwm pun configuration

the problem is still present after commit 8454c9bd799b8f0f97ee32109033cef313092633
works in "added more options"(10/1/2020), does not after it.

[DavidAlfa]

Had a second, Yep, the iron init has a new function to init the timer's timebase detecting the processor speed, to ease the porting between the different stm32, as some has max 36MHz,  others 48, 72...
I forgot to put a line at the end that sets the PWM value that is used to calculate the PID output, so the PWM setting was always 0.
This only happens at boot, you'll notice taht if you go to advanced and change the pwm duty or delay, it works, because in that function it's ok.
Fixed and updated.

Edit: Didn't update, I noticed that disabling the Timer master output does nothing? The pwm stays on!
This is critical for safety control, so I won't update util fixed
Edit2: Ok, That only works in advanced PWM timers that have dead time generation. Not for normal ones.