CFW for KSGER/Quicko STM32 Soldering Stations

[ststefanov13]

Everything should be fixed by now : v1.12.1.

Uhh... I need to sleep, I literally spent the entire night hunting the issues
(And they want me taking beers in 4 hours LOL)


This firmware got pretty complex, about 14K lines of code!
Lots of things are placed in a critical order, and everything depends on everything, it's like playing Jenga.
So it's not easy to optimize or make heavy changes... Well, it's done now!

After power up KSGER 2  firmware 1.12.1:

[asupsp700]

Try to completely erase the chip before flashing it. You’ll just lose all your profile settings!

[ststefanov13]

Triple full flash erase and program and verify same result.

Roll back to 1.10.8 everything is fine.

Proposal to David to form three branches of the firmware: long-term, stable and beta or current.

[asupsp700]

Triple full flash erase and program and verify same result.

Then only David will help! I sewed KSGER_v2_OLED_V1.12.1Beta it up fine.

[DavidAlfa]

Nah don't insist on erasing! No matter how the flash is, it should never fail.
At least that error type is a much easier to trace.

I only have a quicko F103, nothing else, so make me a favour and report properly!
"Show this" is not a description, you're not helping me at all unless you say how to replicate the problem.
Does that error come instantly after flashing? Or after the setup screen?
Make sure you have no protected flash sectors, this is explained in the Github Readme / Programming.



EDIT:
OK! After trying myself several times, it seems to happen after initial system screen (But it shows up), crashing on next reboot?
I spotted the issue, damn, should be the last one!

[ststefanov13]

Nah don't insist on erasing! No matter how the flash is, it should never fail.
At least that error type is a much easier to trace.

I only have a quicko F103, nothing else, so make me a favour and report properly!
"Show this" is not a description, you're not helping me at all unless you say how to replicate the problem.
Does that error come instantly after flashing? Or after the setup screen?
Make sure you have no protected flash sectors, this is explained in the Github Readme / Programming.

After first power up after flash , before setup screen ,  no protected flash sectors.

Roll back to 1.10.8 everything is fine.

[DavidAlfa]

I don't know why my station behaves so well, makes my life extremely hard  .

Please try v1.12.2.

[bozo]

I installed all versions and had no problems. C245,T15,T12 KSGER_v3_OLED.

[Hunghanh2009]

There's something quite interesting. when I flash KSGER_v3_oled v1.12.1 the hardfault error still appears, and that error appears after the setup screen. when I flash v.1.12.0 and v1.12.2(erase chip) it works normally. but when I flashed v1.12.1 again (without erasing the chip), the hardfault error no longer appeared. Once again, I flashed v.1.12.1 (erasing the chip), but the hardfault error appeared again . With the LCD version in KSGER_v3_LCD v1.12.1, I got the same error as the post above, "Line 964 settings.c", and when I restored it to default, it worked normally again. While using the KSGER_v3_LCD version, a hardfault error suddenly appeared. I don't remember which version. I'm just reporting the errors I encountered in both the oled and lcd versions, I hope David doesn't feel upset about it.

[Hunghanh2009]

I installed all versions and had no problems. C245,T15,T12 KSGER_v3_OLED.

Which schematic did you use in the schematic folder? Can you upload them here?

[DavidAlfa]

I don't get upset by the error reports, it's very useful! 
What it does are the reports like "Not working"!
I need to know which controller, which fw version and how to recreate the problem.

Anyways, thanks to the display.c error I was able to trace the issue, I think it should work now in 1.12.2.

[bozo]

My schematic for the t12 chontroller.

[Hunghanh2009]

My schematic for the t12 chontroller.

Thank you. Looking at the diagram, I see that there is a 3.3v power supply circuit for the separate MCU and 3.3v for the separate screen. There are additional inductors and filter capacitors to ensure a clean 3.3v voltage for the MCU to operate most stably, very different from the version I am using which has a voltage regulator circuit from 24v to 3.3v for all (mcu, oled, lcd, opamp...). I think it's not really stable yet.

[elektryk]

Lots of things are placed in a critical order, and everything depends on everything, it's like playing Jenga.

Yeah, I've got a very funny time while merging and modding.
My previous FW for T12 fitted ATmega8 but it wasn't even half as functional.

[DavidAlfa]

Stop talking, try 1.12.2 and tell me!

[elektryk]

With 1.11.7 my board booted ok but with actual release MCU (103CB without battery) is resetting somewhere near showed breakpoints.

After full chip erase it can boot to the first boot screen, I can then click save and after another power cycle only black screen is presented.
EDIT:
Forget debug4.jpg screenshot, debug5.jpg shows actual reason of rebooting.

[DavidAlfa]

Hmm, strange, would you allow me to debug it  remotely?
It's really pissing me off, how in earth is it working for some and not for others?
The flash is the same!
Unless... Some are having different flash sector size... And thus erasing too much?
Otherwise it makes no sense.
Please make sure it's a genuine stm32

I swear I can't make it fail on mine   

Also why Eclipse?
CubeIDE shows a lot more info when debugging, like the last function calls leading to the current position, so you know who called savesettings, why was reboot bit set, and so on.

The reboot bit is set when some data check at boot is bad, performing a scan and setting the defaults in the bad area.

For some reason your's is stuck in a loop, finding bad data everytime it boots.
Must be something really little and stupid!

Also, have you tried button factory reset? (This should never be required, but just as a test)

[elektryk]

Must be something really little and stupid!

Now it boots ok, just see:
settings.c line 562

Code: [Select]

#ifdef ENABLE_ADDONS
    //reset |= loadAddonSettings(); //SUCCESS = 1 so it rebooted then
    if(loadAddonSettings()!=SUCCESS)
    reset|=reset_Addons;
#endif
Another thing, when I edited one of the 3 tips the values changed in each of them, also the save button is present only in the last one added, even though it is not the last one alphabetically.

[DavidAlfa]

- Please report the result of the test below, also specify whether your controller is working with the new firmware.
- If not working, please specify if you're using any clone (Even CKS).
- If not working and apparently not a clone, please run clone detection.

Please don't fill the forum with pictures, just do like:

Code: [Select]

  CPUID: 411FC231        -> Some clones are copying this too! 412xxxxx would be a fake (Different ARM core revision)
  SIZE: 128 KB           -> If this shows 65535 or ???, it's 100% fake!
  Theorical: 1024B       -> Theorical page size based on the reported flash size
  Detected: 1024B        -> Detected page size
  Clone test: 20036410   -> Some clones are copying this ID too!

Yesterday I spent a lot of time creating/changing/copying/deleting tips, switching profiles, everything worked flawlessly here.
What you're doing will cause unexpected behavior, letting the system run with bad settings, then anything can happen then.

This all started after the new temperature storage area was added.
I suspect there's some issue in the flash erasing, perhabs some STM32 are not 64/128K, but 256K or larger, so the sector size will be 2K instead 1k.
This code assumes all STM32s have 64/128KB (1KB sectors), so in larger devices it will erase twice the memory, destroying other areas and possibly causing the system bootloop you got while debugging.
(Bad data->Load defaults->Reboot, Bad data->Load defaults->Reboot...).

This would never be a problem before because the whole settings block was written in a single step.
But now we have sepparated writing areas, so one might be erasing the other!

I made a very simple test to show the reported flash size from the FLASH register.
Whatever the version you're running, this test won't touch the stored settings, so just flash it, show the result, flash the working version back and keep working (Keeping your settings)

[elektryk]

What you're doing will cause unexpected behavior, letting the system run with bad settings, then anything can happen then.

https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Core/Src/settings.c#L562-L581
Well, so even if loadAddonSettings() return SUCCESS (value 1) it should do saveSettings(perform_scanFix, do_reboot)?

[DavidAlfa]

Answering yoru PM - How to debug non-genuine devices in cubeIDE:

- You must set the debugger settings to ST-Link (OpenOCD), or J-LINK with you have it.
  It will never work with ST-LINK GDB server as it performs its own checks.

- In older versions (I think <1.12) you could modify OpenOCD cfg files to bypass the genuine check.
- Recent CubeIDE versions added internal checks... but I was able bypass it anyways .
- You don't need to get your hand dirty, I have already made patches for 1.12.1 and 1.13.0 here.

[DavidAlfa]

Well, so even if loadAddonSettings() return SUCCESS (value 1) it should do saveSettings(perform_scanFix, do_reboot)?

SUCCESS=0

Code: [Select]

typedef enum
{
  SUCCESS = 0U,
  ERROR = !SUCCESS
} ErrorStatus;

What the init does (Simplified) is basically this. Load everything, store any reset flags and reset if necessary.

Code: [Select]

if( bad system settings )
   reset |= reset_Settings;

reset |= loadAddonSettings();                                         // This return SUCCESS if ok, or reset_Profile
reset |= loadAddonSettings();                                         // This return SUCCESS if ok, or reset_Addons

if(reset)
    saveSettings(perform_scanFix, do_reboot);                       //Fix whatever is bad there, loading defaults in the bad area

What I think it's the problem is flashTempSettingsInit(), which will delete its own area, just before the settings block.
If what I said in the upper post is true, it will erase also the settings, r maybe the settings also the temp. block, in a vicious circle.

Sorry, I'm not trying to be a jerk or anything, but I don't want to do twice the job, Developing the firmware + Explaining someone how everything works!
Specially when you're not properly checking things (Where did you get SUCCESS==1?)
Are you letting me debug it out or not? Would make things so much easier for me.
Otherwise I'm running out of patience, I won't keep debugging blindly, with no real hardware in my hands - It's tiresome, slow and time-consuming!

[elektryk]

Thanks for your workaround.

What a joke, the open declaration option brought me here.
CMSIS/device/stm32f1xx.h in AC6

Code: [Select]

typedef enum
{
  ERROR = 0,
  SUCCESS = !ERROR
} ErrorStatus;
BTW If you look at my added if(loadAddonSettings()!=SUCCESS) statement you should notice that in case of error the reset will occur which was desirable.

EDIT:
The same in cube

Code: [Select]

typedef enum
{
  SUCCESS = 0U,
  ERROR = !SUCCESS
} ErrorStatus;

[DavidAlfa]

Code: [Select]

...
  ERROR = 0,
...
  SUCCESS = 0U,
...
The same in cube

Nope, they're completely opposed? How is ERROR=0 in AC6 when it's the same ST libaries?


Try this:

Set battery enabled by default:

Code: (settings.c) [Select]

const settings_t defaultSystemSettings = {
...
  .hasBattery           = false,
...
}

Empty this functions as follows:

Code: (settings.c) [Select]


void flashTempSettingsInit(void){
}

void flashTempWrite(void){
}

void flashProfileWrite(void){
}

void flashTipWrite(void){
}

void flashTempSettingsErase(void){
}


If you don't have a battery, this will cause a Low Battery message on every boot, also forget your last Profile / Temperature / Tip.
But everything else should work fine.

This will completely avoid touching the "Remember Last" flash block, and confirm or discard the said flash problem.

Completely erase the flash using the button factory reset or with the programmer to make hasBattery = true.

[asupsp700]

David, version 1.12.2 Oled 2. Launches and works without failures.
There are two points:
1. Please watch the video https://youtu.be/W2NE7IHkq3Y  - in the tip editor I can only select the active tip for editing.
2. Please correct the information about the firmware version.