CFW for KSGER/Quicko STM32 Soldering Stations

[DavidAlfa]

The graphics are nothing trivial.
The power graph, is basically done by drawing few lines every 20mS to make it smooth.
And the temp graph draws 100 vertical lines every 100mS (10pixel/second).
This mcu can take a lot more! It's only a 128x64 monochrome screen. Also the DMA helps a lot.

The settings screen was removed to free some memory to fit within 10KB RAM.
As in the end I also changed a lot more things, I could free up even more memory.
I agree that the settings screen could be changed.
It might be still  possible to restore the old menu. But I wanted something more direct.
The text is big because it's the same font as the iron error or sleep. To save space.
The settings options isn't a menu any longer, now it's a widget itself, so multiple options can't be seen at the same time.
There are only 7 options, you will get used to them in no time.
At first you'll want to touch a lot of options. You will see it's dead easy. Just get used to it.
Once it's working, the only options you'll ever use will be rise and lower the temperature, little else.
Set the temp step to 10ºC and in 2 turns you will have the whole range.
Sorry, but, if you don't like encoders, I guess you shouldn't buy a soldering station with encoder from the start
I know the encoder  can be a little picky some times. Maybe I'll find the way to make it work better, but I blame the encoder more than the software.
I have 2 quicko boards, one works very nicely. The other has a defective encoder that fails like f**,  working with it makes you want to smash it to pieces!

I totally understand your point of view. And all that can be done of course.
But I repeat my thinking: Only 1% of the people will actuall mess with soldering in these boards.
The whole wiget system is designed to work with the input of an encoder.
I would have to re-design everything, again! As I said, I'm not to up to the labour. I will have to spend a lot of time in something I don't need.
Adding physical buttons to my station, mix it together in the code so they don't cause problems.
Of course they will do, new bugs will appear, again a lot of time debugging.
Then doing it for every board out there, blindly because I don't have any of them. More and more testing.
And the stupid tips getting cherry red and burning everytime a new bug appears or whatever happens.

I'm not being rude or anything like that. I know it might sound like so, but I'm just being clear. Everyone wants their own custom version.
Ones don't like the menu, others dont like the font, others say its too big, others want lot of fancy stuff.
Well, I repeat, I wanted my firmware too, and I had to do it by my own.
I can bend my arm slightly, accept suggestions, but I'm not a programmer working for free, neither I feel pleasure from spending hours frustated, hunting bugs .
They might think doing this is like glueing easy parts together and it's not.
I'm doing all this alone and I'm pretty tired. The project is very far away from what it was at the start.
If anyone doesn't like it, use the crappy stock skger fw. Or the original PTDreamer version.
Hell, it's a cheap controller, not an advanced JBC station
I will repeat again, this is not a new hardware project. It's a firmware for existing hardware.
Anyone can take the code and adapt it to whatever they want.
You can replicate the hardware easily with a blue pill board and few components.
There are dozen projects out there, some pretty nice, with buttons and a lot of stuff.

[dreamcat4]

The settings options isn't a menu any longer, now it's a widget itself, so multiple options can't be seen at the same time.

OK understood. Did not realize this earlier. But looking in your code now... I can see how the menu is being constructed, with successive calls to add_widget(). So it would be a lot more work to change that menu. More than what I was imagining in my head. So sorry sometimes I forget how we do things in embedded C projects. Where many things end up being hard coded.

Sorry, but, if you don't like encoders, I guess you shouldn't buy a soldering station with encoder from the start
a defective encoder that fails like f**,  working with it makes you want to smash it to pieces!

I love encoders! Just not for everything all of the time. But I take your 2nd point is so true, the pain is really felt most of all when the encoder is bad. When they work well it is not such a big frustration..

I would have to re-design everything, again! As I said, I'm not to up to the labour. I will have to spend a lot of time in something I don't need.

That is fine, it is not my intention to create a lot of extra work for you. I think the answer here is to understand how the theoretical idea of clicking a button is more complicated in reality. Than what it might seem. Which I did not consider. Things like:

* If the button is software debounced (by the MCU)
* If the GPIO is hardware interrupt, then it's going to interfere with other tasks
* If the GPIO is being polled instead. Which also requires the opportunity to poll, on a timer. And can miss the signal or otherwise interfere with other tasks.

Sorry for not realizing these details, and not thinking it through. Doing buttons would make extra problems as above. In one way or another. But especially when you are in a phase of maturing the software. I'm sorry to have brought it up again. You just keep asking for suggestions! And the rest is so good that I really cannot think of anything else.

Really I don't mind you rejecting these feature ideas, when it is clear that it would be difficult. It's my mistake for not bothering to check the code. And should think things through a bit more carefully what the complications might be.

And the stupid tips getting cherry red and burning everytime a new bug appears or whatever happens.

Yes this is very annoying. Doesn't stm32 platform have a watchdog timer for that? To catch when the mcu freezes. Or perhaps the feature does not exist on some chips. Or it cannot catch this situation?
 
For example: ...we cannot do something like this?

https://medium.com/@kunalsalvi63/stm32-window-watchdog-94bc0406ea51

I will repeat again, this is not a new hardware project. It's a firmware for existing hardware.

Thank you! Yes I was confusing exactly on this point. Which you made before, but I forgot. What has helped me in particular today was reviewing some bits of your latest code just now. To understand better the way it is written. In those specific areas.... and I did not have to look too hard! Because your C is pretty darn good. Very well written I have to say. It is pleasing to read the code.

But also the method that C requires of writing programs. Which does demand a certain way. It then makes more difficult to make certain kinds of changes on top. This is something familiar to C. And to get into the rhythm of it again. For a productive progress in a session, but without breaking things. I should leave you to it! (as much as possible)

Sorry also for distracting from your other discussions here. For the other boards oled v3.1 etc. That is a more important matter. Lets be clear! Back to that.

[DavidAlfa]

The fact that you can see how the code works is the main thing, now it's a child's game!
That is not a issue, and as I said I'm open to change the menu. But I neither liked the old menu so I have to think something.
My idea was to adding a centered combo widget in the center of the screen. I don't know it the rest of the widgets will like to share their screen with it, but I will try.

Nah, no sorry! I'm not angry or anything, not even close! I just was showing the point!
It's completely normal to ask new features, however I'm actually completely frustrated with the stm32 ecosystem.
Very bad HAL documentation, weird bugs, etc etc... I'd love to add a lot of things, and the huge code changes where aiming to reach a stable and solid fw to work on.
Now, after all that work, a silly HAL bug appears and crashes the system without explanation. I've been trying at it for at least 10 days with no avail.
How do you debug a bug that appears every 2 minutes or 12 hours?
And it's invisible, passes all the checks detect with no problems.  I would set fire to everything right now.
I will take a break for a few days. Then I will be probably fine, with renewed energy to put into this.

[dreamcat4]

Ah so if i understand correctly: it is not MCU freeze then? But instead output stuck on?

In regards to HAL bugs and other issue surrounding HAL / IO systems: I was discussing elsewhere this matter a few days ago and the main finding was that f4 series (and newer) has different HAL that is much better than the older HAL previously for f103 and earlier...

However as we discussed though the F4 package (removed from a black pill) is generally 48 pin. Not 64 pin. So then that option is not so cheap / easy to replace on those 64 pin pcb versions.

But also perhaps another issue around bad HAL. Which is on counterfeit chips not being genuine and manufactured by ST. So the trick (in other thread, we linked before) to better identify the MCU by reading hidden bytes. It might actually make sense to check for this. To make sure the cpu id is genuine and not fake. Bearing in mind that these devices are made in China, and sold on aliexpress.

Yes it is a good idea to take a break. But also the purpose of taking the break is to have fresh ideas when you come back to it. And think differently about the problem. So that a different approach can reveal a different path of actions to take.

What i am saying here is that sometime I take a break for this same reason. But then never think to get the new idea. And therefore don't come back / don't enjoy to return to the problem. Because the situation is left in the same way and nothing has changed. So then I have no new ideas to bring back to the problem! And nothing gets solved. This is particularly true for these more difficult type problem, that is on a critical path. Because the fatigue is being caused not by the workload. But instead by the problem itself. It is being so difficult, which draining of motivation, enthusiasm.

We kind of have to fool ourselves. And just pretend 'well this is not so hard!' In order to forget that sticking point. And push the paper about a bit.

I saw this same exact thing happen to somebody else to, in another project. He kept getting kernel panics (in the linux kernel), the low level networking stack. So what happened? Well he wrote up all of the problem, and described fully everything into an issue. In the project issue tracker. Eventually, a few weeks / months later somebody else came along. And was able to make sense of it. And then the other guy could help, picked it up and was solving a lot of the bugs. And improve the code. That was a critical intermittent bug. It would crash the whole computer.

So I am not suggesting that can be the same solution here. But whatever you do, try to think differently about the problem. To find out about this elusive HAL bug. It seems rather mysterious. Search for links to resources. And searching online for similar bugs. For same mcu, same IO block, etc.).

I also want to ask a question about it: can we sort-of reboot the device. Well not reboot, but instead just re init() the IO block every N hours? For example when it is in idle state. This sounds stupid i guess. But then again if it is a real hardware bug. Then that is often the type of a workaround that makes sense. It depends what is triggering the bug. And the way that you are interacting with the HAL. I guess you just simply don't know.

In some cases it might make sense do realtime trace debugging. To try to catch somehow a unique signature, or 'clues' for what is happening.  Either over the SWD bus, or the other debugging bus. I forget now what it is called. But there is some alternative ultra fast 2 wire bus specially for trace debug on stm32. Then again, you could spend all that effort and time setting up a hardware debugging trace back to your PC. And then if it is a low level hardware bug it just not show up anyhow in the trace!

 

So please, don't listen to me for anything solid. They are just a few different ideas to kick around. Personally I would be trying google, different sets of keywords. Searching around for others with this same HAL bug. Looking for clues.

[jesusvallejo]

Hi just in case gives you any hint, the last git update reports the error in line 554.

[DavidAlfa]

Hi just in case gives you any hint, the last git update reports the error in line 554.

I know, I moved the set oled row to the interrupt itself, as I was doing before.
Its seems to crash less often, at least for me. It's the same crash, but in different place.

Ah so if i understand correctly: it is not MCU freeze then? But instead output stuck on?

In regards to HAL bugs and other issue surrounding HAL / IO systems: I was discussing elsewhere this matter a few days ago and the main finding was that f4 series (and newer) has different HAL that is much better than the older HAL previously for f103 and earlier...

However as we discussed though the F4 package (removed from a black pill) is generally 48 pin. Not 64 pin. So then that option is not so cheap / easy to replace on those 64 pin pcb versions.

But also perhaps another issue around bad HAL. Which is on counterfeit chips not being genuine and manufactured by ST. So the trick (in other thread, we linked before) to better identify the MCU by reading hidden bytes. It might actually make sense to check for this. To make sure the cpu id is genuine and not fake. Bearing in mind that these devices are made in China, and sold on aliexpress.

Yes it is a good idea to take a break. But also the purpose of taking the break is to have fresh ideas when you come back to it. And think differently about the problem. So that a different approach can reveal a different path of actions to take.

What i am saying here is that sometime I take a break for this same reason. But then never think to get the new idea. And therefore don't come back / don't enjoy to return to the problem. Because the situation is left in the same way and nothing has changed. So then I have no new ideas to bring back to the problem! And nothing gets solved. This is particularly true for these more difficult type problem, that is on a critical path. Because the fatigue is being caused not by the workload. But instead by the problem itself. It is being so difficult, which draining of motivation, enthusiasm.

We kind of have to fool ourselves. And just pretend 'well this is not so hard!' In order to forget that sticking point. And push the paper about a bit.

I saw this same exact thing happen to somebody else to, in another project. He kept getting kernel panics (in the linux kernel), the low level networking stack. So what happened? Well he wrote up all of the problem, and described fully everything into an issue. In the project issue tracker. Eventually, a few weeks / months later somebody else came along. And was able to make sense of it. And then the other guy could help, picked it up and was solving a lot of the bugs. And improve the code. That was a critical intermittent bug. It would crash the whole computer.

So I am not suggesting that can be the same solution here. But whatever you do, try to think differently about the problem. To find out about this elusive HAL bug. It seems rather mysterious. Search for links to resources. And searching online for similar bugs. For same mcu, same IO block, etc.).

I also want to ask a question about it: can we sort-of reboot the device. Well not reboot, but instead just re init() the IO block every N hours? For example when it is in idle state. This sounds stupid i guess. But then again if it is a real hardware bug. Then that is often the type of a workaround that makes sense. It depends what is triggering the bug. And the way that you are interacting with the HAL. I guess you just simply don't know.

In some cases it might make sense do realtime trace debugging. To try to catch somehow a unique signature, or 'clues' for what is happening.  Either over the SWD bus, or the other debugging bus. I forget now what it is called. But there is some alternative ultra fast 2 wire bus specially for trace debug on stm32. Then again, you could spend all that effort and time setting up a hardware debugging trace back to your PC. And then if it is a low level hardware bug it just not show up anyhow in the trace!

 

So please, don't listen to me for anything solid. They are just a few different ideas to kick around. Personally I would be trying google, different sets of keywords. Searching around for others with this same HAL bug. Looking for clues.

Yes, that was my  idea. reset the spi and dma and maybe live with it. I'm too perfeccionist and I kept fighting to do in a clean way.
And the fact that didn't happen before is what crisps me more.

No, burning tips is entirely my fault. The normal users have nice protection methods.
When you are debugging for example a strange pid behavior, you need to have the real thing connected. And your stop the core iat certain point to check the variables.
The 99.99% of the times I do it right and remove the handle. The 0.01% that I get distracted looking at the code, and the tip PWM was set to a high value. After 5-6 seconds, say bye to the tip


Might I ask how to do a compare view of a file in 2 different versions, in github?
I've seen that only when that specific file was changed.
Ex. r2636 that file added a line. But since then, 300 commits were done.
So I have to search what was the last commit for that specific file. A total PITA.
Since the oled system and widgets routines are isolated, I can mix old and new the code pretty easily.

[dreamcat4]

Might I ask how to do a compare view of a file in 2 different versions, in github?

sure no problem! It is very easy.

Actually there are 2-3 different mechanisms which you might find useful.

1) The Github Blame button. This appears when viewing a single file. And all you have to do is click it. Then it shows a special 'git blame' view mode. For every single line in the margin it gives the git comit (hash id). And the commit message. Which is a clickable link. So for from there, any line in a file you can jump to the original commit where it was entered.

If there are multiple changes (lines over written). Then the current git blame view will only take you to the last git commit when those lines were updated. But from there is also a special little icon to look back further through the entire history. (for that 1 line of code).

Another way is to click the 'parent' button to go back in the view, to the previously commit (-1). Which is then going to reveal whatever the previous code had already been replaced.

This is assuming that you keep a good git history. And a continuation. Git is usually smart enough to understand simple file moves, or file renames. So long as those operations does not skip over multiple commits.

Help for Github blame:

https://docs.github.com/en/github/managing-files-in-a-repository/tracking-changes-in-a-file


But that is not what you asked for. You asked for:

2) Github Compare feature

This is a hidden url, which you can access by typing:

https://github.com/username/repo/compare

For example:

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

Which lets you compare git branches. BUT that does not show how to compare individual commits. However branches and commits are all just different kinds of git Refs in git. So you use git-ish syntax in the url to specify a commit range. Which can be tags, branches or commits. Whatever.

For example to compare between several commits 'a725d88a' and 'ddcdacecd' you would type the URL:

https://github.com/deividAlfa/stm32_soldering_iron_controller/compare/a725d88a..ddcdacecd

Help for Github compare tool:

https://stackoverflow.com/questions/49837769/how-to-compare-two-different-commits-on-the-same-branch-in-github


And you are done! Well... not quite because you can also:

3) Click the "Create Pull Request" button. To use Github to generate a new open PR. This then also makes it possible to easily generate a .diff or .patch file between 2 arbitrary commits. The resulting text file then makes it very easy to re apply those selected changes from that diff into your working code. As it then becomes just a regular patch file

You take the URL of the pull request, for example:

https://github.com/deividAlfa/stm32_soldering_iron_controller/pull/2

then just add ".patch" or ".diff" to the end of the URL:

https://github.com/deividAlfa/stm32_soldering_iron_controller/pull/2.patch

https://github.com/deividAlfa/stm32_soldering_iron_controller/pull/2.diff

In github... this can only be done for a pull request. Or for a single commit. Unfortunately it cannot be done from the /compare view.

But you can just go ahead and click the "Make PR" button. Then delete the PR when you are done with generating the patch file.

Reference: https://stackoverflow.com/questions/6188591/download-github-pull-request-as-unified-diff


You will find github is a very powerful tool, for searching back in the history. If you also want to do things locally, you can do all the same operations on your local computer too. With other software tools, such as smartgit or the git command line. I also find that Beyond Compare is great tool. For comparing 2 folders outside of git. When they are not properly versioned.

Hope it helps! Good day.

[mastershake]

ill mess with min again tonight after flashing it appeared to have nothing at all loaded. ive flashed stm's before i just ran out of time last night, one question is the 101 in these cases not as good as the 102 stm chips? i found someone local with a handful of new 101's i know they run at a bit slower speed then the 102 generally though i have to check to see which 101's they are

[DavidAlfa]

101s will work correctly too.
The main problem is that I can't test these boards. It's done looking at the specs. Any little thing wrong can make it fail.
I will look again at the schematics and see what could be wrong.

[mastershake]

he has 101 and 102 chips which is why i was asking he said i can take which ever of them i need for nothing but asked which ones i want they are both rb or r8 revision so i assume the 102 with everything else being the same for the slightly faster clock at 48mhz. i saw the 102 offered usb where the 101 doesnt but i dont see that being needed here

im going to reflash it later and see it could be on my end i was in a hurry last night as we had a family member pass and i had to leave in a hurry.

[DavidAlfa]

Yeah you could replace them, specially to not lose the original firmware.
As I said, the 3.1 board is currently untested.
It worked some time ago, but since then I hadn't more opportunities to try it.
I depend on other people to debug these.
For the ksgers, cosmin1 let's me connect remotely and use his computer to debug the boards.
That's how I got the 2.1s to work. He also have the 3.1 but we don't coincide very often.
Now for the 3.1 could be anything, and without debugging it's very hard to find.
If you have st-link and a moment I could try to setup the code and debug remotely using TeamViewer.
I have no dark intentions, but I don't have any other alternative to fix these.

Edit: Well, I tried to use the same display abort routine I use to update the screen when a "panic" error happens.
And it seems to be working. I don't like it to be happening in first place, but at least now it can continue working after the error.
Code updated!

About the performance questions being asked recently: I tested different speeds, and this is what I found.
At 8MHz it crashed, I guess because it was too slow to finish some interrupt before the next call (overrun).
10MHz and upper worked perfectly fine (With SPI DMA). The menu navigation was a little slow but still pretty good.
The main screen, graphs, temp drawing were doing perfectly. So I wouldn't worry.
Software-updated display will be noticeable slower, but anyways I think they will work well with +36MHz devices.
The graphics system won't affect the pwm and such, as these are interrupt driven.
The display might get updated quicker or slower, but the PWM/ADC/PID will be always working normally in the background.
And this is with compiler optimization set for size (Os). With optimization set to "more" (O3) it gains a 25-30% performance at cost of higher flash usage.
128KB devices can use this option without problem. 64KB ones...definitely not.


Dreamcat... I've been checking it. Sorry, all I can say is I hate it, so damn complex, I don't understand why.
Maybe linux lovers like to be typing into a black console for every little thing. I find it anoying!
We are in 2021! Make a simple gui for the everyday use, and the leave the console for what it really is for, fixing something when you screwed it up badly!
They should make the advanced part for anyone who wants to use it, but also a more simple package for normal people.

Like the old SVN. I see I'm not alone :
https://ohshitgit.com/

[jesusvallejo]

 terminal like interface is good when you know what you are doing, i can definetly increases productivity, but on the other hand you end up erasing your fake stm32 in a blink xxdd, i dont like the button in the encoder because they are shit , period, but the encoder makes it straight forward and its already there.i can live with some ghost clicks.

which connector would you guys use(mount on the case) to connect the stand? mb wifi coax, i cant think of a sturdier small connector.

[DavidAlfa]

Yeah for the ghosting I think it could be  fixed somehow by software.
Anyways, I thought the encoder had filtering capacitors. It doesn't. That will cause a hell of switching noise.
The encoder is read at systick frequency, 1KHz. Before it was interrupt-driven and would catch all that noise..
I don't know you, but only problem are the fake clicks. You push it once and it does like 2 consecutive clicks.
Then I also have the screwed encoder that doesn switch correctly between rotation positions and causes weird issues, like nothing at all working until you move the encoder to a stable position.
I will try adding an internal reset function. If the encoder doesn't move for 100mS, reset the position if it was in the middle.
Also don't send buttons clicks if the last one was less than 100mS ago?

The fix seems to be working. All night on, no errors.
I found is that it seems to happen more often if you trigger the handle sensor a lot.
Touching it floating, causing it to catch the 50Hz mains noise, caused the failure a lot quicker, within 30 seconds usually.

The STM32 IDE kept going slower and slower, and the system stuttering like hell althought no visible CPU, SSD or memory use was going on.
I guess one of the thousands weird things I installed didn't go well. I ended reinstalling the whole system, it's like night and day!
It seems to be a computer now, instead of a gameboy!

[jesusvallejo]

yes sometimes the push is not registered and others a double push  but most of the time is ok , rotation always works fine. ill pull and compile new one later and report back. 

[DavidAlfa]

Okay, now I'm officially out for a while. Managed to break an OLED corner while replacing the encoder!  .
It still can be seen partially... looks interlaced, half of the horizontal lines are dead.
Added the delay. Seems to work better. No more double clicks here.

[DavidAlfa]

ill mess with min again tonight after flashing it appeared to have nothing at all loaded. ive flashed stm's before i just ran out of time last night, one question is the 101 in these cases not as good as the 102 stm chips? i found someone local with a handful of new 101's i know they run at a bit slower speed then the 102 generally though i have to check to see which 101's they are

Well, maybe the display info is wrong.
These oleds usually have either 4 or 7 pins (I2C or SPI). That KSGER has a weird 6-pin display with no CS line.
It's very strange that a SPI device has no CS line. I found these displays being described both as i2c and spi in different sites, which seems contradictory.
I smell i2c here... So I made test builds with both modes. Test them, luckly it will work.

Edit: For cosmin seems to be working? (V3.1 with 103RB) Try these files and report.
There are 3 builds: Hardware spi, software spi and software i2c. At least one should work!

[dreamcat4]

Correct me if I'm wrong, but I believe that the OLED display itself, is supposed to be capable of both ways either SPI or I2C. However the newer ksger models use it in I2C mode. Instead of SPI mode.

So the lack of a CS pint should not matter... but even if you wanted to use the 6 pin display in SPI (for a mod, or in a different product). The spi protocols only uses CS when there are multiple devices sharing the same SPI bus.

So you can use SPI without the CS pin... however you then cannot daisy chain extra devices. So my guess: maybe the display does this to force the user to avoid a situation where it shares devices on the same bus. To make sure the data bus is kept free for updating the display only. Without loss of performance or being interrupted. IDK.

Wait what am I saying? You do always have minimum 2 devices on SPI bus. The other one is the STM32 mcu. However because it is a display, it only needs to receive the display data? Then it does not need to transmit back to the MCU and send the other way. Except for something like an ID string, to identify the device. However the MCU does not need such reply, if the firmware is coded to already know which model the display is.

[DavidAlfa]

Yes, the controller is capable of all these modes.
But not at the same time, neither can be freely chosen at any time, it's configured by setting a pin to 0 or 1, usually with a resistor within the board.
I2C bus has addressing so it doesn't need chip selection.
Spi doesn't, so it usually has cs, otherwise you will have to dedicate a interface to only that device, which is a total waste of resources.
In I2C mode, the DC pin is used as LSB bit for addressing, so you can use 2 displays together in the same bus.
The oled pins were correctly configured in the firmware and as I don't have the hardware, I have no clue what's there.
If it didn't work in spi then it must be i2c. If neither, well, I can't help further. Needs debugging.


Edit:
I restored the old settings menu. RAM still has 800 bytes left (9.2KB used).
The encoder still had some false triggering, I added another debouncing timer.

[jesusvallejo]

ive been trying this morning yesterday's version and the screen bug its still there, dont know if it should be solved or not. 

[DavidAlfa]

Are you sure you got the update? Both 072 and 103 have been working correctly for more than a day here.
If it puts the same line number error,  it's definitely not updated.
I found the transfer completed callback might be called without having actually having finished it.
Why the hell do you call it "transfer completed callback" then?
I'm polling it before sending the row command, I'll leave it running and see if it crashes.

This HAL library is total mess.
If you poll for a dma transfer,  and it finished before doing the polling, instead returning ok, it returns error.
It also returns error for true errors, so they couldn't have done it worse.
Wtf ST. Do you use monkeys for programming the HAL?
Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.

[dreamcat4]

This HAL library is total mess.

Hey, just found this 40 pages of errata pdf. It should describe in here all of the known hardware bugs. Might be worth the time reading

 

https://www.st.com/resource/en/errata_sheet/cd00190234-stm32f101x8-b-stm32f102x8-b-and-stm32f103x8-b-medium-density-device-limitations-stmicroelectronics.pdf

[edit] be aware: "medium-density" = 64 pin version.

So there must be other errata documents for the 48 pin count ones, f072, etc

[dreamcat4]

Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.

Is this with i2c bus? Could it be same problem as this other guy found?

https://www.programmersought.com/article/71326761904/

[jesusvallejo]

Are you sure you got the update? Both 072 and 103 have been working correctly for more than a day here.
If it puts the same line number error,  it's definitely not updated.
I found the transfer completed callback might be called without having actually having finished it.
Why the hell do you call it "transfer completed callback" then?
I'm polling it before sending the row command, I'll leave it running and see if it crashes.

This HAL library is total mess.
If you poll for a dma transfer,  and it finished before doing the polling, instead returning ok, it returns error.
It also returns error for true errors, so they couldn't have done it worse.
Wtf ST. Do you use monkeys for programming the HAL?
Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.

im pretty sure, but ive flashed todays last commit and no problems so far in last 2 hours,alot of hours later still going strong

[DavidAlfa]

Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.

Is this with i2c bus? Could it be same problem as this other guy found?

https://www.programmersought.com/article/71326761904/

It was with spi but I think it's dma related, not spi .
Anyways if checking by that it works, it's done.
Edit: Only checking the DMA didn't fix it. Got few crashes.
Reverted the fix to the previous one.

[nkls]

Hello. I flashed my board with version [v3.1] / [64pin] / STM32F103RB. Got artifacts on display, vertical bar on the left. Probably need a different display driver. Can you edit the firmware?