CFW for KSGER/Quicko STM32 Soldering Stations

[DavidAlfa]

I tried once with an almost identical capacitor, when I was fighting with the sensor noise.
Well, it exploded  , maybe wasn't rated for 25V, I don't know!.

Are you sure the capacitor is connected between the heater pins?
100nF isn't a huge capacitance, but can cause nastly current spikes when driving it with PWM.
I don't know how original Hakkos work, but maybe they use 24Vac, in that case the capacitor wouln't cause any trouble.

[ygi]

Speaking of handles, is there a way to use/connect the NTC in a 5 pins handle with a 4 pins station? As I understand it, that's what the 5th pin is for so it's not possible without it but I may be wrong.

[M-Reimer]

I guess one big difference could be the frequency which is used to drive the heater. If Hakko more or less measures around two times per second to then decide for how long of the next cycle they enable the heater (effectively 2 Hz PWM), then the capacitor does not change too much. But if you really use the PWM of the controller set to, for example, 1kHz PWM frequency, then the capacitor has a big impact. But as, I guess, noone in this thread actually owns a legit Hakko station for these tips, noone can tell how they drive the heater.

Probably best I keep with the chinese handle. But I really would like to get the original Hakko stand with the switch. I tried to hack my own but unfurtunately had a minor accident because of using improper tools. So I lost interest in creating my own one.

Any chance that someone here can tell me if this handle: https://www.banggood.com/KSGER-FX9501-Soldering-Handle-DIY-Set-Electric-Soldering-Iron-5-Core-Silicone-Wire-p-1305799.html?cur_warehouse=CN&rmmds=search (chinese handle with the short "finger to tip" distance) fits nicely into this holder: https://hakkousa.com/fh200-01-fm-2027-fm-2030-iron-holder-w-599b-tip-cleaner.html

[TeamTeacup]

Hi there,

This is probably a very simple issue but after going through a few dozen pages I couldn't find a similar issue.

I have a KSGER 2.1S model which looks like an exact copy of one of the boards from a photo in the Github repository. I program the firmware file labelled "KSGER v2.x, JCD T12, QUECOO T12-955" but find that the station doesn't power up.

I've been able to reprogram it with a copy of the original firmware from the repo (thanks for providing this) and it works perfectly once again, I'm sure there's a simple change that needs to be made for my particular board but I'm just not sure what it could be.

[ricktendo]

Any chance that someone here can tell me if this handle: https://www.banggood.com/KSGER-FX9501-Soldering-Handle-DIY-Set-Electric-Soldering-Iron-5-Core-Silicone-Wire-p-1305799.html?cur_warehouse=CN&rmmds=search (chinese handle with the short "finger to tip" distance) fits nicely into this holder: https://hakkousa.com/fh200-01-fm-2027-fm-2030-iron-holder-w-599b-tip-cleaner.html

I do not have a genuine hakko stand like you, but I do have a chinese clone of the stand and that exact iron handle. I am happy to report they do fit together perfectly

[Tugo]

Speaking of handles, is there a way to use/connect the NTC in a 5 pins handle with a 4 pins station? As I understand it, that's what the 5th pin is for so it's not possible without it but I may be wrong.

I don't how 4 pin handle is connected but in 5 pin handle you have 2 pins connected to ground (on the PCB).
Check here: https://www.aliexpress.com/item/32933941125.html?spm=a2g0o.productlist.0.0.25824e14MR1zrh&algo_pvid=d3e4c3f8-d6a4-42a3-ab41-69b8991642be&algo_exp_id=d3e4c3f8-d6a4-42a3-ab41-69b8991642be-59&pdp_ext_f=%7B%22sku_id%22%3A%2212000022941698495%22%7D
G and E (green and black line) are connected together on the PCB board (check bottom of the PCB where you can see G and E markings near the white connector).
I hope that helps you.

[DavidAlfa]

I guess one big difference could be the frequency

A discharged capacitor is seen by the output as temporary short circuit until it charges up. For maybe 10us, there'll be a short but tough current spike, easily exceeding 50-80Amps depending on the wire properties and how fast the mosfet is turned on.
As the frequency rises, so does the number of times it happens per second, beating the crap out of the transistor. Any square pulse of any frequency will cause this problem.
With AC, usually you send half waves, so the voltage will start at 0V and rise evently, the power is delivered in a much smoother way, there's no such sudden capacitor charge.
This fw uses 5Hz by default, if the pid and filtering are properly adjusted it works very well.

I have a KSGER 2.1S model which looks like an exact copy of one of the boards from a photo in the Github repository. I program the firmware file labelled "KSGER v2.x, JCD T12, QUECOO T12-955" but find that the station doesn't power up.

Strange, that's the correct firmware for that board. Anyone having else this issue?
Can you post the log from the programming tool? Try making a full wipe.
The guide to preserve the settings, where you skip erasing the last 2 sectors, is only for settings made by this firmware, so you can update to newer versions keeping everything.
But not for the original firmware, that one stores them in the eeprom, this custom fw doesn't make use of it, so they'll be preserved always.

Speaking of handles, is there a way to use/connect the NTC in a 5 pins handle with a 4 pins station? As I understand it, that's what the 5th pin is for so it's not possible without it but I may be wrong.

In a 5 pin handle, the wiring is typically like this:
- Power
- NTC
- Shake
- Ground from power supply (Common for ntc, power, shake)
- Chassis earth (isolated from power supply ground)

I guess a 4-pin connector joins earth and gnd, like this:
- Power
- NTC
- Shake
- Ground from power supply + chassis earth

Quicko (Not Queeco) uses a 6-pin plug, it's  similar to the 5-pin, but with 2 ground wires, no NTC (in-board) and has a second sensor input for a different heater type, I guess for hakko 936 heaters, which use a PTC sensor.

Adapting the wiring isn't complicated, but you must check the connections in your board.

[wickated]

I guess a 4-pin connector joins earth and gnd, like this:
- Power
- NTC
- Shake
- Ground from power supply
+ chassis earth

this

[TeamTeacup]

Strange, that's the correct firmware for that board. Anyone having else this issue?
Can you post the log from the programming tool? Try making a full wipe.
The guide to preserve the settings, where you skip erasing the last 2 sectors, is only for settings made by this firmware, so you can update to newer versions keeping everything.
But not for the original firmware, that one stores them in the eeprom, this custom fw doesn't make use of it, so they'll be preserved always.

I've attached a log from another attempt about an hour ago, I've been performing a full wipe with each attempt and it seems to all go through just fine. It programs and verifies just fine both with this and the OFW I'm using.

Here's a copy of the log.

[DavidAlfa]

Is anyone running the latest fw in a Ksger v2.1 board?

[ricktendo]

Is anyone running the latest fw in a Ksger v2.1 board?

Hello David, tested on this 2.1 board revision and I can confirm NO issues with the latest firmware.

[ygi]

I guess a 4-pin connector joins earth and gnd, like this:
- Power
- NTC
- Shake
- Ground from power supply
+ chassis earth

this

Yep, I just finished rewiring the handle and that's what I have (that's why I asked in the first place). Anyway, the Handskit 5 pins handle turned out to be a 4 wires cable with a 5 pins connector so there isn't even a NTC inside to worry about.

Thanks for your input guys.

[DavidAlfa]

Thanks, Rick
TeamTeacup, can you make pictures of your board, specially showing the stm32 in it?

[TeamTeacup]

Here's both a full shot of the board, and a closeup of the STM32. I did my best with contrast to make it as easy to read as possible.

[DavidAlfa]

Hmm everything looks correct.
Have you tried downloading the file again just in case?

[TeamTeacup]

I downloaded the same file and they both have the same SHA-1 checksum to them, I'm not sure if it'll be the same for anyone else but the files I'm receiving are at least consistent.

I'm using the ST-LINK Utility, though its with a reprogrammed STM32 development board that behaves like an ST-LINK. That's about the only rogue element I can think of, but given it could program the original firmware just fine I'm not so sure.

[DavidAlfa]

I don't think so... Try this file.
It's a display test I made a while ago when adjusting i2c timings.
No pwm, ADC, flash settings..everything is disabled and unused except the display.
Another way to check what's going on is to install stm32 cube ide, import the project and start a debugging session, if anything crashes (hard fault, whatever) you'll be able to see it.
I think it's possible to use a st-link remotely, ex. connect to your stlink from here, but I've never tried.
I wonder why it's not working, if you want to try just send me a pm

[ricktendo]

I also use the old stlink utility to flash mine, only difference from yours is I updated the STLinkUSBDriver.dll (v6.0.0.0) file and flashed the latest firmware V2.J39.S7 on my stilink

https://www.st.com/en/development-tools/stsw-link007.html

[illiac4]

I guess a 4-pin connector joins earth and gnd, like this:
- Power
- NTC
- Shake
- Ground from power supply
+ chassis earth

this

Yep, I just finished rewiring the handle and that's what I have (that's why I asked in the first place). Anyway, the Handskit 5 pins handle turned out to be a 4 wires cable with a 5 pins connector so there isn't even a NTC inside to worry about.

Thanks for your input guys.

Did you rewire it? Andy why have you rewire it? I know that it is not compatible with Ksger handle wiring.

[TeamTeacup]

I don't think so... Try this file.
It's a display test I made a while ago when adjusting i2c timings.
No pwm, ADC, flash settings..everything is disabled and unused except the display.
Another way to check what's going on is to install stm32 cube ide, import the project and start a debugging session, if anything crashes (hard fault, whatever) you'll be able to see it.
I think it's possible to use a st-link remotely, ex. connect to your stlink from here, but I've never tried.
I wonder why it's not working, if you want to try just send me a pm

The I2C timings firmware file seems to have the same outcome for me, nothing appears on the display. Perhaps the particular I2C OLED module thats in this station needs compensating for. 

[DavidAlfa]

To accomodate every single display out there, I made the timings a lot slower than they used to be, so I doubt it's the problem here.
More like the stm32 is failing to run?
I mader a simple diagnostic fw, should output a number of beeps on every initialization step (from 1 to 9).
After the 9th beep, the screen should turn on. If it makes any beep, at least we know the stm32 is working.

[TeamTeacup]

Aha, I guess that means the STM32 isn't initializing then. It doesn't beep at all.

As for debugging it in STM32CubeIDE I'm not sure I'm doing it correctly, but I have the project files opened and all set up for debugging. And it seems to halt at line 89 of main.c:

   int main(void)
   {
     /* USER CODE BEGIN 1 */

     /* USER CODE END 1 */

     /* MCU Configuration--------------------------------------------------------*/

     /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  ->  HAL_Init();

     /* USER CODE BEGIN Init */

     /* USER CODE END Init */

     /* Configure the system clock */
     SystemClock_Config();

     /* USER CODE BEGIN SysInit */

[DavidAlfa]

There's something wrong there. HAL_Init should be line 167. So there's a lot of code missing.
Are you following the project generation steps?
- Run the script _KSGER_v2.bat, in the root of the folder.
- Open stm32 cube ide, import an existing projectn and select only the file that appears in the root of the folder, unselect those inside the BOARDS folder!
- Double click STM32SolderingStation.ioc to open cubeMX tool, and click on the code generation button, it's the orange gear, close to the build button (hammer icon).
- Now the code will be complete. You should see this sections in /Src/main.c:

Code: [Select]

/* Private variables ---------------------------------------------------------*/
ADC_HandleTypeDef hadc1;
DMA_HandleTypeDef hdma_adc1;
CRC_HandleTypeDef hcrc;
IWDG_HandleTypeDef hiwdg;
TIM_HandleTypeDef htim3;
TIM_HandleTypeDef htim4;
DMA_HandleTypeDef hdma_memtomem_dma1_channel2;
/* USER CODE BEGIN PV */


Code: [Select]

/* Private function prototypes -----------------------------------------------*/
void SystemClock_Config(void);
static void MX_GPIO_Init(void);
static void MX_DMA_Init(void);
static void MX_ADC1_Init(void);
static void MX_IWDG_Init(void);
static void MX_TIM3_Init(void);
static void MX_CRC_Init(void);
static void MX_TIM4_Init(void);


Code: (main) [Select]

  HAL_Init();
...
  SystemClock_Config();
...
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_ADC1_Init();
  MX_IWDG_Init();
  MX_TIM3_Init();
  MX_CRC_Init();
  MX_TIM4_Init();


Make sure you're running a debug build. In the hammer icon, click the downward symbol, select Debug, and it will compile for debugging.
Go to the HAL_Init() line and make double click in the line number to set a breakpoint there.
Then start a debuggging sesion by clicking over the downward  symbol in the debug button (green bug), select"Debug configurations", select "STM32SolderingStation Debug".
In Startup section, check that "Set breakpoint at main" is disabled, and finally click on Debug.
It will program the stm32 and start the execution until reaching the breakpoint we set earlier on HAL_Init.
Now check the small arrows im the debug area: "Step into", "Step out" and "Step return".
- "Step into" dives into the code on the function, ex. in will enter HAL_Init() and step through its code.
- "Step out" will skip the details and execute the function "silently".
- "Step return" will execute everything and stop at the end of the current function.

Given it seems to stall in that HAL_Init, use "step into". Once inside it, use "step out" to execute each function without entering them.
At some point you will see that it keeps running indefinitely, that's because the function didn't return (it's stuck somewhere) so hit the suspend button, and you will instantly see where the program is at.
Now make "step into" and see what's the code causing the endless loop.

[TeamTeacup]

If I'm not mistaken, it seems to be stuck on line 493 as part of Error_Handler but that might just be the expected response from the STM32. The debug panel to the left shows it occurred during SystemClock_Config() so that may be the point at which is actually had a problem and it just jumped here as a response.

Apologies for any difficulties I'm giving anyone with this, debugging and using any IDE is new to me for the most part.

[DavidAlfa]

Please attach the file main.c
Doesn't make any sense, error handler isn't empty on my code... I think you made something wrong.
Watch the video on GitHub that shows how to correctly import and build the project.
In any case, hal_rcc_init is failing, so run step into, and check what's causing that.
If you have a moment, I can have a quick check using TeamViewer, just send me a pm.