CFW for KSGER/Quicko STM32 Soldering Stations

[Il_Marco]

I decided to go for a Bangood offer of a complete Ksger unit (fully assembled and with its handle), just because I think it's a good value to get it a try (32,5€ shipped). It should have (but who can tell?) A V2.1s r2 controller (based on your good work dreamcat4) and the JBC T245 (R7) option. I really hope that soon or later, thank to the work of all of you guys, I would be able to use it with my T245 handle and tips. I'll wait till I receive it and then, based on what I receive, buy a pair of spare STMs. I still hope for DavidAlfa to port his work to JBC T245. Maybe I can ship you a pair of weared C245 tips (I'll wait fir some trashed ones in next month) for you to experiment without burning good tips. It would be my help to the forum.

[DavidAlfa]

Well, this  are my first steps on github... Tried to make the build process as easy as possible.
https://github.com/deividAlfa/stm32_soldering_iron_controller
Already compiled bins if anyone wants to try.
Keep in mind that only the stm32f072 is tested! Made for the Quicko T12
The stm32f103 is done "theorically".  Made for the original 1.5 controller.

Dreamcat4, I checked your code, damn, lots of bugs I found were already corrected on yours... so much pain for nothing! 
Anyway, as I said, I didn't knew the existence of your fork until it was done!
There's no sense in making separate projects, so now it would be nice that you tell me a bit how is yours doing.
I saw some exotic math functions (I guess for making the averages or what ?),   "flawless adquisition" (what was the problem with adc?)
What is the status of the porting bertween the different board revisions (1.5, 2.1, 2.1s....so on)?

[dreamcat4]

Yeah this all looks fine. I do really agree you should be the new lead developer / maintainer of the code. Network graph shows well the situation:

https://github.com/deividAlfa/stm32_soldering_iron_controller/network

Thanks for taking the time to learn the git, and also to make these instructions and guidance for others what to do / how to build. And for different hardware. It's really helpful and I cannot thank you enough.

Might send you a small PR (merge request) over on Github to fix the docs a little bit. But it's not anything important. Just small housekeeping.

Overall I am really looking forwards to following your new instructions and trying this out on my Ve2.1s ("r2") board I have here. And see how far I can get along with this one:

https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#blue-pcb-ve21s-r2-ksger-version-lwfp-64

More generally, it would be nice to raise the awareness level for others. To get more people each with different boards. So we can have greater level of community participation and contributions for the many other versions of this hardware.

[DavidAlfa]

I would be happy to help!
I checked the 2.1 schematic and I must say it's pretty sad, we'll see how the ADC works with that 3.3V buck converter noise...and the op amp has no filters!

[dreamcat4]

Not a problem!  I have already got here the needed replacement 3.3v regulator, and the replacement op-amp. Which were ones recommended by the Russians. These should be ok once I install them. Going by those other people's past comments (in the radiokot forum).

[DavidAlfa]

oK. I saw the display uses i2c instead spi on these. Luckly my screen has a resistor to switch between modes.
I thought about it, to not overcomplicate the code, I will just make different branches for each controller.
That way the STMCUBE project can be used right away without needing any tweaking from the user side...

[dreamcat4]

The problem with making seperate branches or codebases is then it creates a burden of extra work, keeping them all in sync with each other. Things become harder the more different hardware to support. And there are so many different boards.

What I was hoping is that we can have multiple project files, and then choose which one to compile for a specific build target.

It is a good idea to put different hardware features under configuration. This then also lets people to mod their devices and select (for example) and alternative display etc. by selecting a combination of options to compile in.

Of course the code generation aspect makes things more difficult. In the past I have used autotools. And other ones. But those are not necessarily best for this project IDK. Perhaps there are many possible build systems to choose from.

On a feature level. For example I2C vs SPI display. Then I would like to #ifdef stuff condifionally in the c code to compile in and out the specific features. Then have something in the build process to select which ones to compile.

What do you think about this?

[DavidAlfa]

But that way we'll have to put thousands of #ifdef.

Stm32 Cube Ide doesn't handle well switching between MCUs, that was my initial intention.
But the project creates a lot of problems,conflicts between HAL Drivers, startup code, linker script, and after changing all that, you find that the project  mcu is hardcoded and can't be changed in it's properties.

The  only way to not make it painful is to make it fully compatible with CubeMX code generation. It will make all the pin definitions, etc...
You can switch between .ioc files, yes, but again, only if the exact same mcu is used. And adding further confusion.

My thinking would be to share the common code , but let the specific part separated. We can share most of the code, but not the main, setup.h, IDE project and cubeMX files.
I don't know if that could be done and how.
Take a base for all, then each branch  would add its own specific files, but taking any change from the base code.

[dreamcat4]

Well being on linux, we have symlinks. So my own thoughts is to write a shell script that will let somebody 'create' a new folder. Containing just only those files you mentioned:

> the main, setup.h, IDE project and cubeMX files

By copying from a template or default folder. So then you end up with 1 folder per hardware configuration. With users having a way to just run a command to generate a new hardware configuration, into it's own folder.

Then (in linux, because we have 'symlinks')... we can have the same script also then symlink the common folder into that hardware configuration folder. So that it is a subfolder. To share all of the common code.

This might be a problem! because in windows you don't have symlinks. But instead have 'Shortcuts' .lnk. So then it would be more desirable to be having the possibility to reference the common code via a parent relative folder ..\Common\ (or whatever it is called).

And have relative paths.

Otherwise you are forced into using WSL, which inside WSL 'kindda' has symlinks. But also not really so great. It would be preferable not to have to impose the requirement of WSL onto windows users.

[dreamcat4]

Or perhaps if we ever try PlatformIO, that itself will come with helps mechanism(s). Which are cross platform compatible. But right now it seels like we don't have the time to invest the efforts to try to switch over to that yet. And since we both can use CudeIDE well enough, it compiles things. It works.

 

In terms of making separate per folder configurations.... Hopefully once I get the opportunity to work on this project next week, maybe the choices for how to do that... might become a little bit more obvious.

 

But what I can say (for sure) is that maintaining multiple branches in version control across multiple users is a complete nightmare. I have done so before in past projects and it is utter dridgery. We should to our best to stick to 1 main development branch ('master'). This greatly simplifiers user contributions. We should switch back to 'master' already. I just didn't make / send you a PR yet. Next few days.

 

In terms of #ifdef #elif preprocessor macros. Well again - I have used these too previously. Also in other (much larger) C projects than this one. They are by no means perfect. And like you say can make the code really untidy. However at the same time they are normally the right fit for a C project.

But I think it's helpful to talk more about how to use them properly. To address your concern that there would be '#ifdefs everywhere'. Because that certainly can happen too, without managing them properly.

Also the point of them is to be feature based. So taking the screen for example. There should only be 2 options. Either it is i2c, or its spi.

Basically there are 2 ideal instances where #ifdefs are not going to hurt your eyes... Either:

* It's a larger C file, and within it there is only a couple of places where you need some simple #ifdef #elif. OR that is some #define constant macro. That is a choice between preset values. Great. Then they are not going to be so frequent.

* If there are many extensive changes throughout the file. OK in this instance we don't want to #ifdef around specific lines of code. But instead of that pull in a completely different .c or .h file. So instead of putting them into the code, we reference the other file we are compiling in. For example via #include. And then have different 'variants' of the file. One for each #ifdef or build flag. So then we are either compiling 'timers_hw1.c' or 'timers_hw2.c'. And only the reference file needs to have a few lines in it to control which one was picked up. Be it for include, or compiling / linking.

By copying the entire file (timers.c --> timers_hw1.c). But then edit each file individually. And have to maintain multiple different files. For each independant feature we have under configuration. However in this way, we can develop all the code in the same VCS branch. And no need to keep many different git branches. Just because having many branches to maintain... that would be much less pleasant way. Trust me you don't want to merge stuff like that. It's terrible. (nightmares, I still remember).

 

[DavidAlfa]

After an afternoon fighting to implement a DMA i2c rotuine (the damn CubeMX didn't enable the i2c interrupts by itself), then I found that... well,  I'd like to know what these chinese programmers were thinking!
Having a 64 pin mcu, only ~20 used, why the hell they plugged the i2c devices to non i2c ports?
As if i2c wasn't slow enough! Use software i2c! Spend 80% cpu cycles sending a year 2000 phone resolution display!
I seriously think  that these board don't deserve any development. Pure crap!
I could design a pcb, then anyone could order 5 from jlcpcb  for $5!
Yes, in the end maybe the cost is a little higher having to buy all the componentes, but it would be a decent hardware to work with...

[dreamcat4]

Custom board is certainly a very good idea. Actually others have already thought about that, over in the Russian forums. There was a guy on radiokot selling such pcbs for a while, to the other russians.

The main thing to realize is that the current solution is to buy the original v2.1 hardware, which is for sale on aliexpress. This was the version of the board which has been copied the most by people who make their own PCB.

Here it is:

https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#v21s-original-version-green-pcb

So another solution is to writing in bigger, bolder letters the correct hardware to buy. As above^^. Right at the very top of the README. So it's more obvious to see it. Instead of those warnings being so hidden away.

 

As for my inferior garbage blue Ve2.1s board here, with the i2c display. i am not against cutting traces, scratching off copper. And putting little fly wires across to other pins. In order to re-wire the i2c display, if necessary.

Uhm I don't know if this could be compatible or not. But another component already on order (sorry I forgot to mention before). Was 1x SPI oled display for a completely different project.

https://www.aliexpress.com/item/32896971385.html

It is still in the mail, coming from china. If it's compatible then perhaps I could connect that one instead. To try it out first. Before cutting traces and ditching the i2c display completely.

Which solution is best? IDK. But those seem to be the current options for modding (on that specific one).

Anyhow yeah I agree it's frustrating and not very rewarding to give effort to supporting inferior boards. When you know full well it's not right. So maybe if we can come up with a reasonable hardware mod, and document for others how they can also do that for theirs. To rewire their boards. Because that's the situation for most people: they buy the garbage ones. Or don't know which board they are getting, because it's hidden in the enclosure etc.

 

[DavidAlfa]

The OLED is not hard to fix, the I2C pins are free.
Being i2c we can share the same bus between the oled and the eeprom.
There's no need to cut the traces, just configuring them as input will be enough.

[DavidAlfa]

The porting was pretty simple. About 10 minutes...
Here's the stmcube ide project, already compiled (.bin inside Release folder).
About Vstudio code, I tried setting up all the stuff, definitely not for me, a total mess, and repeat when you make a new project.
Plus I had to manually go to Tasks...Clean, Tasks...Build, Tasks...Run........... everytime!.
I'm pretty stuck to eclipse, although I like a lot more the way Microchip did it.

So, just solder these two wires (ignore the eeprom for now) and report! Nothing is adjusted in the ADC part, but the Vinput should work, and the NTC if it's the same type...

The thermocouple op-amp does roughly the same as in the quicko, except that in the Quicko it's divided in two stages.
But the final gain is similar, 234 on the Quicko, 250 on the KSGER... The temp will be a little lower on the KSGER.

Sadly the 103RC doesn't support I2C fast mode plus (1Mhz). We could manually try oveclocking it a bit, but first see that it works!

Although the ssh1106 datasheet tells that the max rate is 400Khz, it worked perfectly at 1Mhz on my stm32f072...We'll see.

[dreamcat4]

Thank you.

Currently waiting on some better amtech flux in the mail. Because the pink chinese stuff has bad fumes. When my flux arrives... later this week.

Then the plan is to:

*replace adc
* replace 3.3v regulator
* replace mcu
* remove eeprom, its not currently being used, right?

Because the closed firmware uses the eeprom, i will probably try to back up whatever 'lock codes' or calibration settings are stored on it be the commercial firmware for back up purpose.

Ok. So the i2c bus display mod looks great. Because anybody can do that, it does not hurt anything.

So my main question is should I delay replacing the ADC and the 3.3v regulator to begin with? To know the behaviour with the stock component.

The other thing I could spend time (wasting time on), is setting up an arduino to talk to this thermocouple module. To take independent temperature measurement. To be able to cross check what the actual temperature is. However I dont know how well that is going to work. It is just a regular thermocouple. If it can adhere and stick to the blob of molten solder at the end of the tip. Or if you need some more special equipment IDK.

Thanks for checking out the vscode platformIO, and setting up the cubeIDE/MX project here for my board! This has saved my time, as otherwise would have taken longer to get to this point. Although that would have been fun too! However skipping that part lets me get on to the hardware mods.

Always getting interrupted, doing other things in-between which are not related. Hopefully by next week. Looking forwards to this!

Today was spent rewiring a T12 handle back together. Nearly broke it. What a mess. And the big knife tip was no good after all. It's too long for regular tasks. No contact area. Should have gotten something else instead. Like a bevel tip. Damn. Anyhow it is what I have to work with for the time being.

[DavidAlfa]

I don't think the main problem is the regulator itself.
Stepping down 24V to 3.3V with a linear regulator will build a lot of heat.
Only 50mA will cause more than 1W of heat, in than small board it will overheat easily and start throttling.

I have these and are great: Small, efficient and very convenient.
https://es.aliexpress.com/item/32768078949.html

I suggest to use a buck converter like these to step down the 24V to 5, then the LDO to give clean 3.3V.
There's a big design problem anyway... it's using the same supply for the analog and digital parts.
The analog supply should be, at least, filtered with small choke (inductor) and complemented with more capacitors
Replacing the ADC? I guess you were thinking on the ADC but actually wanted to say a different thing?

I wouldn't remove anything, this is just a test to see if it works. The eeprom will remain untouched, so no problem.


I'm actually fighting with a bug, the i2c will work on first boot, but no more after posterior reboots.
The OLED inits, but then the I2C hangs at the first DMA transfer. Dang...

[dreamcat4]

Yeah sorry it was late in the day. I meant to say "Op-Amp" there. And not ADC.

 


Understood. It seems I already have a different buck/boost converter my drawer. That also covers enough the right voltage ranges:

https://www.amazon.co.uk/dp/B011P8IW4Q

As you say to reduce heat dissipation in the linear regulator (final step). It makes sense to add this. Thanks!

[DavidAlfa]

It depends. Measure the current, maybe it's low enough that it doesn't worth it.

[dreamcat4]

OK Cool.

Unforunately just had an accident. While waiting for my Amtech flux to arrive.

 

So far, had:

* Setup my MAX6675 thermocouple, and checked it's accuracy against ice water, boiling water, body temperature thermometer. Check.

* Checked the performances of my other irons:

ts-100, bc tip
====================================
350c = 240c

oled v3.1 'r1' cfw, knife K tip
====================================
350c = 250c

oled ve2.1s 'r2' blue,, knife K tip
====================================
350c = 250c

Those were the maximum steady state reading after some time 'settling'. 1-2 mins. So they all seem to have a 100c drop, between the internal temperature reading inside of the tip. Compared to what the k-type thermocouple was sensing across the molten blob of solder, and through it's protective metal tin can.

* It was not yet possible for me to measure or plot the power draw. But I do have 3 very large shunt resistors. 15A/75mV. That would have taken more time to setup.

* Started to make a chart, to measure the temperature fluctuations behaviour.

The next step was replace the op-amp. And also upgrading the step down voltage regulator that goes from 24v to 3.3v. To compare the smoothness / noise of the temperature fluctuations. Before and after. This way I can be confident to know it works. Not to have to guess what might cause any potential performance issue is in the software or hardware. Should that be the case.

Unfortunately as I finished my 1st chart, I put the handle into the holster. An had to bend down to unplug the PSU from the AC power socket on the floor. While my attention was diverted I missed what happened. But it seems to be that the MOSFET shorted out. And created a small fire on the back of the board.

Up until then I had been running the iron constantly at 350c for some minutes. To plot the chart. So I am unsure what the cause was. It could have been any one of these things:

* If I had run it too long. And the MOSFET got too hot over a long heating time.
* If something shorted internally inside of Handle. When I replaced the handle in the holster.
* If when i leaned down, it moved the PCB around on my desk, and shorted against either the thermocouple can (housing), or some little solder blobs. I don't know!

The mosfet was on fire for about 5-7 seconds. Images attached.

When my amtech flux comes, I shall remove the mosfet and nearby components. And see if the PCB is too damaged. Or can be repaired. Sorry to let you guys down and set things back. For testing the open firmware.

The other problem might be I don't have exactly the same mosfet to replace. But I do have a few other mosfets for other project(s). If they are compatible or not, IDK. Will have to check.

OR I could 'borrow' the mosfet from the other OLED v3.1 'r1' green PCB. https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r1/front-display-hw-sw-version.jpg Which is currently seems working OK / fine. That other controller was the one needing the 48 pin package F103. Which as we discussed was to take off from the Chinese "blue pill" clone board. Which is not genuine ST F103, but a chinese clone MCU.

I was trying to avoid it for now. Because you said yours had died. And I just didn't want to damage mine either. Since I only have 2 of those "blue pill" boards. And they are cool to have around for general use.

After I get my amtech flux I will post more images. To better see the damage underneath. And check what mosfets I have. Without having to wait to order replacement parts, which would delay things.

[dreamcat4]

OK so...

* The burned mosfet (on the Ve2.1s 'r2' blue PCB) = AO4409. Dead.

What I have:

* The mosfet on the v3.1 'r1' (green pcb, working) = TPC8107
* My 2 spare mosfet (meant for other project) = TSM4459

Maybe they are compaible ? IDK. Have not checked yet. Just making a note of it. Then again maybe the PCB is killed. So it cannot be repaired. Then there is no point speculating.

I can also look for other MOSFETs in my junk pile. Some recycled PCBs from other thrown out appliances. Those component should be in good condition and all working. To remove / scavenge from.

[Nicky_F]

Custom board is certainly a very good idea. Actually others have already thought about that, over in the Russian forums. There was a guy on radiokot selling such pcbs for a while, to the other russians.

Russian guys from radiokot forum are just copying original schematic and making pcbs for their dimensions and needs. And usually people are making pcbs for combo option (iron + heatgun), because it is overpriced on aliexpress.

* The mosfet on the v3.1 'r1' (green pcb, working) = TPC8107
* My 2 spare mosfet (meant for other project) = TSM4459

Maybe they are compaible ?

Any p-channel mosfet with low Rds(on), voltage 30+V and drain current 10+A will be good, such as TPC8107 (like you have on green v3.1), IRF7240, IRF9328, AO4407, IRF9310. Btw, TSM4459 that you have will be very good option for replacing burned TPC8107. I think your board is fine, except for burning traces, maybe electrolytic cap is also dead due to overheating, and check transistor which controlling gate of mosfet, most likely he's also dead.

Sorry for language mistakes, english is not my native language

[dreamcat4]

* The mosfet on the v3.1 'r1' (green pcb, working) = TPC8107
* My 2 spare mosfet (meant for other project) = TSM4459

Maybe they are compaible ?

Any p-channel mosfet with low Rds(on), voltage 30+V and drain current 10+A will be good, such as TPC8107 (like you have on green v3.1), IRF7240, IRF9328, AO4407, IRF9310. Btw, TSM4459 that you have will be very good option for replacing burned TPC8107. I think your board is fine, except for burning traces, maybe electrolytic cap is also dead due to overheating, and check transistor which controlling gate of mosfet, most likely he's also dead.

Sorry for language mistakes, english is not my native language

Thank you, my friend! Very grateful for this comment. BTW the quality of your english was also perfect, along with the advice too.

 

[DavidAlfa]

With what firmware did that happen? If the mosfet heatsup, its probably caused by bad switching.
Ex. high frequencies, lots of rising and falling time, specially with that switching circuitry, the gate transition is pretty slow.

That's why I went to 50Hz PWM. Also the power supply noise at 1KHz PWM was unbearable.
Yep, the chinese used the frequency that us humans hear the most!

The AO4409 has 7.5mOhm RDSon. That shouldn't be a problem.
At 5amps (Far over from this application, should be in the 3A range) on-state the losses would be ~0.2W.
With only 4.5V Vgate it's 12mOhm, so 0.3W. Nothing to worry about.
The AO transistor are pretty nice stuff. I've seen them everywhere, specially in laptop motherboards.
Yep, they fail from time to time, but usually on 10+ year old devices with a lot of running hours over them.
It also happens with IRF and similar makers.

So, don't replace the mosfet for now! First we should understand why it happened.

I also made a little mess with my second board.
I was probing the mosfet source, the probe slided and bang! Direct short between gnd and the mosfet output..
Don't tell anyone, they might think I'm a newbie at electronics 

Althought there are gate resistors, mosfets usually short out all pins, so that means 24V everywhere, including the gate.
That's why it's important to isolate them somehow from the MCU.
Check that the Q2 didn't blow too, and that the STM32 pwm output still works.

[DavidAlfa]

I've been fighting hard with the stm32 library for a whole week.
My intention is to set the max pwm to around 98% and set a Timer trigger when the output goes low, that directly fires the ADC without software intervention.
I knew the HAL documentation was bad, but now I must say it's absolutely horrendous.

Hey, you have to use HAL_ADC_DMA_blahblah. OK. It works in single ADC mode. Every time the Timer PWM resets there's new ADC data.

Now, in ADC interleaved mode (For faster adquisition) it either works all the time or it works only once, and there's no way to start it again, neither by disabling all the DMA and ADC stuff and then re-enabling them.
How the fu** do I retrigger it?
Ah, you have STM examples. Done in 2012 with a outated library that it's nowhere close to the actual HAL. And set in DMA continuous requests mode that never stop.
Reference manual explains a sh**, "bit for DMA continuous mode request" 1=DMA Continuous mode enabled, 0=no continuous mode.
Oh, yes, that explains it much better. Thanks!
Fu* you ST!
I've tried to find STM32 technical books. Checked them all. All do the same, basic stuff.
"STM32 Arm Programming for Embedded Systems". Looks nice huh?
Open it and you'll see that half of the books explains how a transistor works. Lets's blink a led.OMG...
The title should be "STM32 introduction for dumbs". I intentionally bought it from amazon knowing I could return in within 14 days, returned it after 5 minutes!!
Yeah, I know how to convert a single ADC channel and poll for the conversion till it  finish. Crap.
STM is BS. Very nice on paper... but on real world...!


I love so much how Microchip libraries are made. Just the way the SFRs declarations are done, and it's bit fields, 1000 times better!
I hope they move on and catch ST soon. They've done a nice step buy ATmel, but still the fastest MCU is 300Mhz while ST has 550MHz one, also have dual core versions!
Although the peripherals are getting better, they still added LCD hardware and DRAM controllers pretty recently, while ST had done that in 2010 or so.


Let's compare two situations. You want to enable ADC1.

In Microchip:
All the registers are declared in the libraries as in the datasheet. Every register, every bit. So you don't need pointers, structs and all that crap.
You have ADC1CON1 register. But also ADC1CON1bits bit field.
It's easy as

Code: [Select]

ADC1CON1bits.ADON=1;// Enable ADC1
ADC1CON1bits.ADON=0;// Disable ADC1

BUT in STM32 you dont have access to ADC registers directly. They use relative addressing. A mess as you will see.

Where's ADC1 declared? Inside stm32Fxxxx.h:

Code: [Select]

#define PERIPH_BB_BASE        0x42000000UL
#define APB2PERIPH_BASE       (PERIPH_BASE + 0x00010000UL)
#define ADC1_BASE             (APB2PERIPH_BASE + 0x2000UL)

All that is done in:

Code: [Select]

#define ADC1                ((ADC_TypeDef *) ADC1_BASE)
So ADC1 starts at 0x42012000. Nice. No problem for now.

I want to enable ADC1. From the Reference Manual, I should set ADON bit in CR2 register.

Where's ADC1 CR2 declared? Nowhere! There's a generic struct:

Code: [Select]

typedef struct
{
  __IO uint32_t SR;     /*!< ADC status register,                         Address offset: 0x00 */
  __IO uint32_t CR1;    /*!< ADC control register 1,                      Address offset: 0x04 */
  __IO uint32_t CR2;    /*!< ADC control register 2,                      Address offset: 0x08 */
  __IO uint32_t SMPR1;  /*!< ADC sample time register 1,                  Address offset: 0x0C */
  __IO uint32_t SMPR2;  /*!< ADC sample time register 2,                  Address offset: 0x10 */
  __IO uint32_t JOFR1;  /*!< ADC injected channel data offset register 1, Address offset: 0x14 */
  __IO uint32_t JOFR2;  /*!< ADC injected channel data offset register 2, Address offset: 0x18 */
  __IO uint32_t JOFR3;  /*!< ADC injected channel data offset register 3, Address offset: 0x1C */
  __IO uint32_t JOFR4;  /*!< ADC injected channel data offset register 4, Address offset: 0x20 */
  __IO uint32_t HTR;    /*!< ADC watchdog higher threshold register,      Address offset: 0x24 */
  __IO uint32_t LTR;    /*!< ADC watchdog lower threshold register,       Address offset: 0x28 */
  __IO uint32_t SQR1;   /*!< ADC regular sequence register 1,             Address offset: 0x2C */
  __IO uint32_t SQR2;   /*!< ADC regular sequence register 2,             Address offset: 0x30 */
  __IO uint32_t SQR3;   /*!< ADC regular sequence register 3,             Address offset: 0x34 */
  __IO uint32_t JSQR;   /*!< ADC injected sequence register,              Address offset: 0x38*/
  __IO uint32_t JDR1;   /*!< ADC injected data register 1,                Address offset: 0x3C */
  __IO uint32_t JDR2;   /*!< ADC injected data register 2,                Address offset: 0x40 */
  __IO uint32_t JDR3;   /*!< ADC injected data register 3,                Address offset: 0x44 */
  __IO uint32_t JDR4;   /*!< ADC injected data register 4,                Address offset: 0x48 */
  __IO uint32_t DR;     /*!< ADC regular data register,                   Address offset: 0x4C */
} ADC_TypeDef;

And where's ADON declared? Nowhere as itselft, but as a mask:

Code: [Select]

#define ADC_CR2_ADON_Pos          (0U)                                         
#define ADC_CR2_ADON_Msk          (0x1UL << ADC_CR2_ADON_Pos)                   /*!< 0x00000001 */
#define ADC_CR2_ADON              ADC_CR2_ADON_Msk                             /*!<A/D Converter ON / OFF */
So there's no direct definition for all the peripherals registers, neither its bit fields.
You must create a *ADC_TypeDef pointer and assign it to the ADC base address:

Code: [Select]

ADC_TypeDef Adc1 = ADC1;
And still, we don't have direct access to ADON bit.
We have to play with masking:

Code: [Select]

ADC1.CR2 |=  ADC_CR2_ADON;         //ENABLE ADC1:

ADC1.CR2 &=  ~(ADC_CR2_ADON);  //DISABLE ADC1:
In Microchip this would have been simple as:

Code: [Select]

ADC1CR2bits.ADON=1; // Enable ADC1
ADC1CR2bits.ADON=0; // Disable ADC1

All I see is that ST implementation is unnecessary overcomplicated. Why so much mess?

[dreamcat4]

With what firmware did that happen?

It was the Chinese commercial firmware it came with.

The AO transistor are pretty nice stuff. I've seen them everywhere, specially in laptop motherboards.

Then I shall spend the time to see if I have anything suitable in my junk drawer... it's just slow to identify random mosfets on random boards. To check they are suitable.

So, don't replace the mosfet for now! First we should understand why it happened.
...
Althought there are gate resistors, mosfets usually short out all pins, so that means 24V everywhere, including the gate.
That's why it's important to isolate them somehow from the MCU.
Check that the Q2 didn't blow too, and that the STM32 pwm output still works.

Thank you. OK yes, I should try checking the MCU boots and was not destroyed. After cleaning it up and removing the existing blown mosfet. Then I can also investigate to see if the pins of the dead mosfet are shorted to each other.

If you don't hear from me it's just because I am still waiting for this amtech flux. They messed up the delivery, or I will need to re-order it all over again. Whichever the reason.

I knew the HAL documentation was bad, but now I must say it's absolutely horrendous.

Yeah I understand it's difficult to use ST libraries. They like to make life difficult. I suppose you cannot use the HAL ADC abstraction library, for example like this?

https://electronics.stackexchange.com/a/202952/206468

Perhaps because it requires an extra code generation step? Which then fixes to a specific hardware? Actually if you follow the link in that post, is included a tutorial about it. The complexities we must put up with. Yeah I agree simple things like this should not be even half so difficult. ST overcomplicate.

BTW For other smaller new projects (not this one), my wish is to try the Rust programming language instead. And just avoid this ST stuff completely. Of course learning Rust is it's own burden / overhead. But they provide their own system of interfaces / rust HALs. To provide that abstraction layer. And of course Rust is not limited to only ST hardware. It also includes HALs for the other manufacturers.

However it's not suitable for this existing project. And of course most other developers use C/C++ instead. Not many people use Rust yet. It is still developing. Better to try on smaller, more simple projects first.