PR: Fix MKS H43 hard crashes on (at least) STM32 platforms #24025
Conversation
|
Confusion: I just looked at MKS's own "latest" firmware for their Robin nano STM32 boards. The "nano" series boards also use STM32 chips, yet they are advertising the H43 plugged into one of these boards and apparently working. Sure, the home screen shows up but I swear it does NOT actually work and for reasons well understood to me, after hours of debugging to find the cause and fix it. Stuffed if I know. Are they falsely advertising just to clear old stock or something? :/ Or is something nonsensically amiss in my own little universe? Wouldn't be the first time. Your call. I've done all I can. |
|
I wish I could test, but the H43 I got from MKS was DOA. |
thinkyhead
force-pushed
the
PR_MKS-H43_STM32
branch
3 times, most recently
from
73a96b8 to
25dd374
Compare
thinkyhead
force-pushed
the
PR_MKS-H43_STM32
branch
from
25dd374 to
da44f3a
Compare
I have a working H43 that I can test with. I can't say I remember having crashing issues when I first got this screen and I'm pretty sure it was with a 32-bit board, but that was quite some time ago. Once I resolve the build errors with my current board/config (stock bugfix/outside of this PR), I can test these changes. |
Maybe I do too…. There are different adapters, and I don't know that I tried them all. |
thinkyhead
force-pushed
the
bugfix-2.1.x
branch
2 times, most recently
from
a059328 to
c9a9b25
Compare
thinkyhead
force-pushed
the
bugfix-2.1.x
branch
2 times, most recently
from
627f8ef to
20dea22
Compare
thinkyhead
force-pushed
the
bugfix-2.1.x
branch
2 times, most recently
from
97117d0 to
5979aab
Compare
thinkyhead
force-pushed
the
PR_MKS-H43_STM32
branch
from
e01ef41 to
1c3ef80
Compare
thinkyhead
force-pushed
the
PR_MKS-H43_STM32
branch
from
1c3ef80 to
32c6d50
Compare
|
Seems to build now after some corrections. But will it work? |
|
Merged the latest code, so is this still needed? |
|
The PR was needed and worked perfectly at the time it was submitted but it seems core development accelerated faster than we could keep up. :/ I am not able to test due to, well, life changes, sorry. What to do? The crash was real and the original PR at the time corrected the problem without issue. Core development went faster than we could keep up, I think? No one else came forward with the same display who could run tests. So I guess, even though the work was put in to fix it in good faith, perhaps we now have to drop this fix? I don't know what else to suggest. I feel bad about it. Apologies. |
|
I still can't get mine to work correctly and from what I've seen, this is a common issue. Maybe it only works with older versions of Marlin? It's a bummer since the panel & UI looks pretty good. |
thinkyhead
force-pushed
the
PR_MKS-H43_STM32
branch
from
7967a15 to
4e5f56d
Compare
|
I've merged these changes into the newer PR #24600. If that PR is in good shape then it can be merged today. |
Description
Fixes MKS H43 (DWIN/DGUS) code from crashing STM32 mcus.
Requirements
Makerbase MKS H43 touch display and a 32-bit controller board it can connect to.
I suspect this same problem exists for all the DGUS displays on 32-bit boards (like DGUS Reloaded etc) but I have only addressed the MKS code in this PR.
Benefits
The MKS H43 display now works under STM32 builds instead of hard crashing Marlin when a user attempts most any interaction.
Note that as far as I can tell from reading about, the existing code (prior to this PR) works on 8-bit systems but is nevertheless in violation of ISO C11/C99 pointer casting rules, leading specifically in this case to the aforementioned hard crashes for SMT32 builds under GCC code optimization.
Configurations
Configurations.zip is attached.
My test platform is a BigTreeTech SKR mini E3 V3.0. The included
platformio.iniis for that particular board.Note that this v3.0 board has changed from the infamous
STM32F103RCT6to the newer (and actually available)STM32G0B1RET6MCU. Older versions of PlatformIO do not include this newer chip so upgrading may be required.Any
STM32family MCU board should suffice for testing however. I know the issue exists on the BTT SKR mini E3 V2.0 and theSTM32F407ZGT6based BTT SKR Pro 1.1.Oh -- I actually upgraded my SKR mini E2 V2.0 board's MCU to the RET6 version in order to run Marlin 2 with all the features I have enabled. The stock
RCT6version should be OK here though, since most of those features are disabled by default.YMMVThe H43 requires merely GND, +5V, RX & TX on any available serial port, such as
EXP1,AUX1orTFTlabelled ports on various boards. I'm using theEXP1port on the SKR mini E3 v3.0, pins 1, 2, 6 & 8 respectively.Related Issues
I have not raised an issue concerning this bug and cannot find any directly related open issues at present. Pretty sure I have seen them before and there's definitely some scattered forum and Reddit posts. Either way, the current
bugfix-2.0.xcode is broken in this context as described. (Also broken in2.0.9.3, which I was actually working with when debugging the issue. There are quite a few other differences in the DGUS code there too, compared tobugfix-2.0.x. So I re-applied the fix manually for this PR, rather than stomping on the other changes.)Makerbase themselves appear have ignored the problem, most likely because they are working with the MKS Robin controller and that apparently works just fine.
I have owned this MKS H43 screen for well over a year now and it has never worked for me — even with Makerbase's old Marlin fork they released that works fine on the MKS Robin, at least. (I only have 32-bit platforms.)
There must be a fair few of these display tossed into drawers in disgust. So, I hope people find this and it makes their day or something.