CFW for KSGER/Quicko STM32 Soldering Stations

[totalnoob]

@floobydust - Vulkan's photos in his response (photo 2452) looks exactly like that. 

@Vulkan - Do you have any links to sellers of that handle (i.e. the first one with the better connectors to the JBC tips), or, if the PCB was sold separately to be used in a donor handle, the PCB seller?

Thanks. 

[vulkan35]

Do you have any links to sellers of that handle

907&JBC

936&JBC

Controller 2020 STC T12-951 JBC T245-T210.

T12-951

[dreamcat4]

I cannot match the controller pcb from these existing images. Perhaps a new and clear photos of the PCB, front and back. That should help to identify it. If you have the time.

[totalnoob]

Do you have any links to sellers of that handle

907&JBC

936&JBC

Controller 2020 STC T12-951 JBC T245-T210.

T12-951

Great, thanks!

[totalnoob]

I cannot match the controller pcb from these existing images. Perhaps a new and clear photos of the PCB, front and back. That should help to identify it. If you have the time.

If you mean, the photos I posted, I think part of the problem is that they used black for the PCB color.  It's hard to make out even looking at it in real life under the lighting in my office, which is quite well lit.  I will do my best, but I can only guarantee that I will attempt to get better photos of the back.  I'm sorry, but I am not good at de-soldering things and I need this station for my RAS restoration project, so I don't want to go experimenting before I can get that little bit of soldering done.  If I can pull the PCB out without having to de-solder it (I saw one nut that is going to be a bear to try to get to without de-soldering the handle output, the potentiometer did not look too bad), I will take photos of what I can, but I realize there may be components and traces hidden under the display which would need to be de-soldered to see what's under it.  I may try it later, once the RAS project is done.

[dreamcat4]

No no sorry. The message was for vulkan. just didn't highlite him.

 

[vulkan35]

I cannot match the controller pcb from these existing images.

T12-951 on the processor STC15F2K60S2, HW not compatible with STM32.

Perhaps a new and clear photos of the PCB, front and back.

Photo from seller version 2019, version 2020 added another MOSFET.

In the settings menu there is the possibility of accurate calibration of cartridge thermocouples.

Settings menu:
op amp gain: default 250, range 100-350, usually do not need to be changed.
offset voltage: default 0, range 0-400mV, usually do not need to change.

All users who buy a single PCB can request an open source firmware for the soldering station after assembly is complete, but do not allow personal distribution.

[dreamcat4]

The MCU is not STM32, it has marking "STC" but the part number is too blurred to read. I wonder if it's STM32 clone (licensed compatible). Or if it's not STM32, then the firmware will be different.

I would suggest that if the debugging port is not SWD.... then it's not compatible.

[vulkan35]

it has marking "STC" but the part number is too blurred to read.

marking STC15F2K60S2

[dreamcat4]

Intel 8051 clone

http://www.stcmicro.com/datasheet/STC15F2K32S2_Features.pdf

[islonina]

I don't see firmware for my board. I know that is stm32 f072cbt6 from this link https://pl.aliexpress.com/item/32963498371.html Menu doesn't have tip selection and font i very small

[DavidAlfa]

It's the same as mine.
I already reversed it few pages back, it isn't so different, the problem is that the pinout is totally off...
https://www.eevblog.com/forum/index.php?topic=105869.msg2551614#msg2551614

Actually trying to figure out how to modify it in stmcube, it's driving me crazy!

Added pinout comparison:
https://docs.google.com/spreadsheets/d/1XHaR4yQGOzwOOm_SS0sypfmvLkAiSz8K8jxcwVk1R-8/edit?usp=sharing

[cosmin1]

I posted this on another thread since I had indicated I would.  I am also going to post these here so that this thread can consolidate the information in one place. 

I just received my "V3.1S"  Attached are photos of the controller.  The first is intended to be a high res photo of the controller built up using 3 close-ups that are pieced together using Paint 3D.  I did this with the idea that it would remain legible at higher magnification.  It's not perfect, so you may see some inconsistencies between the "joints".  I also took a single photo of the controller.  I also took a closeup of the STM32 chip, but that may have to go in a separate post due to the size of the photos.

I got the same version right now.
Surprisingly i have the JBC options in menu, from JBC1 to JBC8.
HW 2.00, SW 2.12.

I have 2 questions:
1. as the processor is very hot, it helps if i put a heatsink on it? I can not hold my finger on it, i think it has about 50-60 Celsius.
2. I suppose if the JBC is present in tip menu, i can use those tips too. Where can i find the connection diagram for this?

[cosmin1]

Can someone please confirm, is it normal for this STM32 to work at 100 Celsius? Or it's defective?
100mA current consumption.

[DavidAlfa]

100mA at 3.3V is 0.33W, by no way it should get so hot.
Are you sure the heat is coming from it and no other part? Like a regulator.
Does it get hot without connecting the handle? Maybe it's the mosfet.


BTW @dreamcat4, I can only say, the STM32 ecosystem is a total mess.
I tried few years ago, I see it has become like arduino, new version to fix the older and cause more bugs, you can never make a damn thing easy.
I'm a microchip fan, although no so powerful as stm32, their documentation is way better. And the dev tools.

I've replaced the stm072 with a 103 from a bluepill. And trying to adapt your code.
Adjusted the ADC inputs, the EXTI GPIOS, all the inputs, outputs, the PWM channel and the spi interface.

Or everything is bugged or I don't know whats happenning. I started with a easy part, the screen.
Just use the spi2 module instead the spi1. The CS, RES, DC signals work. Transmiting a byte makes a signal on the spi output.
Sadly I lost the logic analyzer and I dont know what the hell is happening. The SPi configuration is the same for both channels, just replacing spi1 with spi2..., tried lower baudrates, no way.
In the end I throwed all the spi hardware to the trash and implemented a software bit bang spi. Bingo the screen works.
I've read that the spi module is kinda problematic in the stm32... Maybe the counterfeit stm32 is even worse!

The encoder is very erratic. The rotation works if I spin it quickly. The push button is like magic, sometimes it work, sometimes it doesn't, often works if I push and rotate. Very strange.

Some help would be great!


Edit:

The .ioc file seems to be totally off. The encoder push button is not configured in it, althought it appears in the code.

Check it up, download your git... PB5 shows empty. ADCs are strange too, signals are duplicated and set to both ADC?

Also, the interrupt-on-change shows in FALL mode, setting it to rising and falling fixed the encoder.
Another problem taken from the stmcubemx. In your code is set ok!
It's like if the ioc is not synced with the code. Like if it was from an older build.
Another headache is the user code, it's not set between the comments //User code begin  //User code end,  etc, so Cubemx erases everything after generating code.
It's far from being usable, dont know if it's a CUBEMX problem or what... tried with the fw 1.4.0 (it says it was the version used to make that project), also tried to migrate to the latest...

When I dropped that way and started fixing the code by hand it got better... hehe

[DavidAlfa]

Well, finally. Everything works.
I have only one problem. How to calibrate the NTC? It measures 56ºC in a pretty cold day.

Also, I don't know if it's a bug or what. Heating the NTC with my finger, if it goes past 65.5ºC it goes back to 0! Once it cools down a bit it returns to normal.

Did you code the uGUI yourself, by hand? Amazing work! My poker face when I tried to understand everything was epic 

[dreamcat4]

Hey DvidAlfa, I am glad to hear your efforts. It is very encouraging.

I actually didn't touch the code myself, except to get it to compile cleanly. Other people were hacking on it in that branch for the v2.1 support. So what you see in their git history comment (since PTDreamer) is stuff like... maybe they didn't understand what was going on with the temperature readings and were trying to either fix or improve that. Unfortunately some subsequent versions of the KSGer v2.1 hardware actually had bad components on them around the 3.3v regulator that powers the ADC, and also the opamp that amplifies the thermocouple signal before it gets fed into the ADC pins of the STM32.

This is discussed elsewhere. But the question remains if those guys were genuinely trying to fix a real software bug. Or chasing their tails because they didn't realize the temperature errors / swings etc were all down to bad hardware. And were successively changing some parts of the code without any benefit for that reasons.

OK so all that aside, you can see I have given instruction for STM32CubeIDE in my docs. However I really do agree with you many of these difficulties with SMT32 platform in general, and also their dev tools (the code generator etc.). And also their libraries being difficult to use, etc. BUT you already know that!

What somebody else pointed me to (after I had wrote that guide) was that it's also entirely possible to do STM32 development on PlatformIO (in VSCode, using the PlatformIO plugin system). This environment is actually also quite complex itself. But one of several great feature it has is that it can automatically import and setup the required STM32 libs as dependancies. So we are not completely shackled to the STM32 manufacturer provided dev tools.

I just thought I should mention that.

And of course the chinese clone versions of the STM32F103 chip are in fact subtlety different. So you might have hit one of those very not so well known differences in the chip around the IO blocks. Not the same! It's terrible I know in fact was complaining myself about this matter elsewhere. It is really a minefield and pretty confusing situation without kind people such as yourself figuring this out (mostly the hard way) and then making clearer comments in the code and documentation for others to be aware.

I'm not going to be working on this code anytime soon myself. However I do really appreciate and want to support your efforts here on this branch however I can.

Thing is in the last couple of weeks a competing project has also now opened up his source code. But that is a completely different hardware. It has been my goal to eventually get them both going and compare the 2 options against each other. Very exciting! (aside from those terrible bugs i'm sure you will agree).

 

Finally I do hope you fork the repo on github, and upload yourself your own changes into a new branch perhaps? It would be nice to share amongst others. To see what you have had to fix, and how.

You need to learn git? There are resources to help. It isn't that difficult. Personally I use SmartGit on linux. But if you are on windows (or mac) there are other options for a GUI Github client.

Have a nice day.

[cosmin1]

100mA at 3.3V is 0.33W, by no way it should get so hot.
Are you sure the heat is coming from it and no other part? Like a regulator.
Does it get hot without connecting the handle? Maybe it's the mosfet.

Absolutely sure. I touched the CPU with my finger but can't hold more than 2-3 seconds. After 5 minutes even the board is pretty hot and no other component.
100mA i measured on main power of 24V. So he's dissipating about 2,5W of heat.

[DavidAlfa]

Well, once you get the IDE running, it goes like butter.
The STM072 gave me errors when I tried to debug, in all IDEs! While the 103 worked fine
So it was a PITA to figure out what the problem was, every time.
Like we say in Spain, translated is like "hitting the blind", you feel but don't know why or where! 

Like Windows in the old days, crashing very, very often, but without blue screen, just a red led of death lol.
Then I found that the SPI DMA copuldn't be active when enabling some parts of the initialization process.

Then, suddenly SW4STM32 crashed, lost all the build configurations, couldn't make, debug, program...
I said few not so pretty things, deleted SWSTM and installed again stmcubeide...
Guess what? It imported the bugged project perfectly! Just minor errors because I had to add few include paths. And even debugs!!

Now its working with DMA assisted display, which updates almost asynchronously, so now it really goes fast!

Now I put back the stm072 in its board (lucky survivor, I soldered/desoldered it at least 5 times, all pins are doing well still), and I'll go with the ADC now.
It reads ok, but the factors are totally off.

And!!! I fixed everything in the code to be CUBEMX friendly, so now you can touch any settings of a GPIO, ADC, Timer... And keep everything nice and happy!
That was a big part of the trouble too...

By the way, I found some source codes for the STC T12 irons, they are very much like baseline pics, 16fxx and so, few instructions and a delight to program without loosing 200 hairs per hour.
However I'm not aware how the ICSP programming goes.

[dreamcat4]

Now I put back the stm072 in its board (lucky survivor, I soldered/desoldered it at least 5 times, all pins are doing well still), and I'll go with the ADC now.
It reads ok, but the factors are totally off.

For some models there is known hardware issue with certain components. It affects the temperature readings. I am not sure if its same problem for you here. BUT

We regularly talk about these 2 connected problem:

* The 3.3v regulator can be bad. And give bad unclean power to the op-amp. ---> The solution is to replace it with a better one.

* The op-amp can also be bad. ---> The solution is to replace it with a better one.

Because an inferior VRM will create noise on the line, is will throw off the sensitive reading from the thermocouple.

Because the op-amp itself can be inferior quality, and not good enough to amplify the delicate signal (microvolts). Before feeding in the result to the ADC.

In both cases it messes up the temperature reading. You want a smooth an continuous change in the temperature. Instead of the numbers jumping about everywhere.

We can give recommendations for replacement parts, for the KSGER T12 (v2.1) station. Just need to dig around to find them. As the are not in front of me right now.

Or perhaps that is not your problem? Then perhaps it is something else?

 

And!!! I fixed everything in the code to be CUBEMX friendly, so now you can touch any settings of a GPIO, ADC, Timer... And keep everything nice and happy!
That was a big part of the trouble too...

Good news. Please click the "Fork" button on github. Upload and share with the world. Thank you!

 

[DavidAlfa]

Nope, Vcc is fine. The adc reading are consistent. About 5bits of noise (4mV).
If you see my schematics, the VCC is well done in this board.
First is uses a buck converter to step down the voltage to 5V and supply the OLED screen.
Then a 3.3V LDO for just the stm32. The voltage is is stable at 3.299v.

It's the algorith used. Some constant is wrong.
The NTC function uses 16 bit value for reporting mCº, so going over 65.5ºC ( 65535mCº) saturates the variable and rolls over to 0.
The whole gui use also 16bit values. So not so easy to fix.
That will fixed be later, for now I want to adapt the conversion of adc, as the opamp circuit is different.

NTC final calc voltage using Vref has an error about 10mV. Which can be the voltmeter error easily.

The calculation algorithms don't use the vref input for anything! It uses a hardcoded voltage of 3300mV.
Simple as Vinput=(3300/4096)*Adc_reading.

The VCC may (And will) vary and affect those calcs. Vref is not used anywhere in the whole program.

I will share it of course, still have to polish it a bit more. Too much hardcoded values, hard to modify in an easy way.

[floobydust]

Also, a bug in the cold-junction comp is using the station outdoors it can be below 0ºC (in Canada) and it bungles the sign change.
Temperature should be a signed variable to avoid wrap around.

[DavidAlfa]

There were bugs on dma transfers, the adc was filling only half of the buffer, and in FOR loops (specially on the cold function part).
Another strange bug causing Hard faults was that "sizeof" was returning 0 in part of the loop for calculation the average.
I guess it's a compiler bug, but I had to replace the sizeof with a define.

I replicated the cold function algorithm in excel and the results are totally different.

Code: [Select]

static const uint16_t NTC_R = 1013;
float adc_read = log(NTC_RES);
adc_read = 1000 / (0.001129148 + (0.000234125 * adc_read) + (0.0000000876741 * adc_read * adc_read * adc_read));
adc_read = adc_read - 273150;  // Convert Kelvin to Celsius

The actual adc readings was about 2307 (1.85v).
The final result on the stm32 gives 80895.

As the result is truncated to 16bit, which results in 15359.
Units are mCº, so you might think it's ok because you see 15.3ºC on the screen. But it's not.


Finally I dropped the method using logarithms and float numbers. That thing was cursed.
It makes no sense, the cpu doesn'h have FPU, those calcs consume a lot of processing power.
Using a table based routine showed to be very accurate, the error is about 0.2ºC.

Now the temp works between 0 and 125ºC. Still finding how to show negative ones.
I think it's a uGUI fault, yet to find if it's wrong configured or a limitation.

I'm replacing a lot and making the  code more versatile, there's too much stuff hardcoded, I just hate when I just change a timer or an output and also have to touch up 20 lines of code everywhere.

I haven't programmed like this for years, back then I was a nice amateur coder, but then you start working and not having time for anything...

But you never forget the IF...ELSE...WHILE... like listening to my my ex gf, how many times had I think "Where's the Control+C" 


I'm still amazed how the gui works. The widget system built on top of uGUI is to joke!

[cosmin1]

I'm back with news. The STM is bad.
Measured 3,27V on pins 48 & 64, 1V on pin 13, 1,7Von pins 19 & 32.
Question is: if i replace it the STM32F101 with a new one, can i get it to work?
The board is HW 2.00, SW 2.12.

[DavidAlfa]

Do you have stlink for programming?
I have almost finished  fixing the firmware, after that it should be very easy to port between stm32 variants.


The last changes were to stop ADC DMA being always in circular buffer.
The DMA routine was called every 300uS, which makes no sense, a waste of processing power just entering and exiting the callback.
ADC DMA changed from Dual simulntaeous conversion to single ADC mode.
There's no need of so much speed, and that way the compatibility is improved, as the STM32F0xx devices only have one ADC.
It may be even faster  than before, as the sampling time was set to 239 cycles, while 13 cycles is almost the double needed to charge the internal hold capacitor through a 10K resistor.

So now the ADC is updated every time the PID is called (much often than the OLED update).
Actually the PID routine is called every 1mS and the OLED updated every 10mS (We got a 100Hz gaming screen lol).
The responsiveness of the GUI is perfect now.
Before it wass updated every 200mS and the encoder responsiveness was cluncky.
Added delay for the GUI readings update. By default update is done every 200mS, don't recommend going faster as you will only see numbers dancing.

PWM frequency updated from 2 to 24KHz to stop the annoying beeping, while adding 33% more PWM precision.
This still need testing, as the mosfet driving circuit may be too weak, resulting in the mosfet gate floating at a intermediate voltage and acting as a a resistor (lots of heat).

Anyway, the circuit is wrong anyway, because the mosfet gate absolute max voltage is 20V and this circuit is driving it at 24v!
I will add a mosfet driver to fix this. Most people should maintain the 2KHz frequency unless they know what they're doing.

Fixed the NO IRON crash.  Added 1000mS delay to prevent bouncing back to temp screen.
Fixed NTC temperature readings. Will limit output between "-9.9" and "99.9" ºC.

I think I will reorder the main screen too. The release will be soon.

BTW, the "Btech" logo and all the files signed by "Jose". Who did this? Was this a leaked code from a company? Or a hobby project of is employeers?