eeprom save fix AUTO_BED_LEVELING_BILINEAR with a 8x8 (and bigger) mesh

[ThomasToka]

Description

On TMC2208_STANDALONE with AUTO_BED_LEVELING_BILINEAR and GRID_MAX_POINTS_X greater 7, so as of 8x8 a crc mismatch occurs on reboot. Mesh and other settings can be generated and saved but on printer reboot everything is resetted.

Error:EEPROM CRC mismatch - (stored) 57991 != 44219 (calculated)!

UBL works still. It only affects AUTO_BED_LEVELING_BILINEAR as of 8x8.

With this fix the problem is solved.

Benefits

eeprom saving is possible

Configurations

TMC2208_STANDALONE on a Ender 3 S1 Pro

Related Issues

#26144

[ellensp]

extra #endif at 1501?

[ThomasToka]

oh sorry. you are right. corrected.

[RV-from-be]

@ThomasToka and @thisiskeithb
It is a possibility but in fact it is due to the EEPRom Size defined in dwin.h (jyersui) by:
static constexpr size_t eeprom_data_size = 48;
On my custom build based on jyersui and integrating a host of extra functions and hence extra data into the EEPRom, by increasing the definition of the variable above, no issue. I went up to a value of 176 (for test) without issue.
For the current Marlin bugfix, setting the variable as follows fixes the issue.
static constexpr size_t eeprom_data_size = 64;
And not necessary to modify settings.cpp

[ThomasToka]

i did it with jyers, proui, creality dwin and lcd_rts.cpp. all the same. why the bilinear saves „mesh“ mesh leveling data? if one switches it will be all resetted.

[RV-from-be]

i did it with jyers, proui, creality dwin and lcd_rts.cpp. all the same. why the bilinear saves „mesh“ mesh leveling data? if one switches it will be all resetted.

By conscience, I compiled from the current bufix, a jyersui 10x10 ABL version without any modification (On an Ender3 V2). No problem found, no data reset or anything else weird. So I now conclude that it is more of an EEEprom issue with the Ender 3 S1 F4. Searching the web, other users report problems with the EEprom based on Marlin sources and not going back to the Creality firmware affecting only the Ender3 S1 F4...

[ThomasToka]

M851 Z2
M500

reboot.
z offset is 0 then.

i can sent you a pronterface log with debug enabled in around 2h.

[RV-from-be]

M851 Z2 M500

reboot. z offset is 0 then.

i can sent you a pronterface log with debug enabled in around 2h.

Maybe with Ender3 S1 F4, but if I do what you just did on my Ender 3 V2:
M851 Z2
M500

reboot and...My Z-offset is 2 !

[ellensp]

@RV-from-be If you look at original issue, you can see that I tested on the simulator and a Creality v4.2.2 and could not replicate this issue...

[ThomasToka]

i am very thankful that you care. and also understand if you can’t replicate.
will also try to increase the value.. i don’t care if my pr becomes obsolete when i set eeprom size.. I just want to have my printer working also with a 10x10 abl mesh.
Will be back at my desk in around 2h and post my result.
but it is like it is an my f4.

[ThomasToka]

jyers work when i increase it dwin.h. that i can confirm for now.

EDIT: trying now to adopt this for my lcd_rts.cpp ;)

[mriscoc]

Maybe this is related to a very old resolved bug: mriscoc/Ender3V2S1#125

[ThomasToka]

Maybe this is related to a very old resolved bug: mriscoc/Ender3V2S1#125

Could you please point me to your commit for this? Cant find it :-(

[ThomasToka]

I can confirm that disabling crc check fixes it.

But thats not the propper solution i think.

[classicrocker883]

@ThomasToka and @thisiskeithb It is a possibility but in fact it is due to the EEPRom Size defined in dwin.h (jyersui) by: static constexpr size_t eeprom_data_size = 48; On my custom build based on jyersui and integrating a host of extra functions and hence extra data into the EEPRom, by increasing the definition of the variable above, no issue. I went up to a value of 176 (for test) without issue. For the current Marlin bugfix, setting the variable as follows fixes the issue. static constexpr size_t eeprom_data_size = 64; And not necessary to modify settings.cpp

in dwin.h if you look at class JyersDWIN is it significant that these values add up to 58??

corner_pos is set to 10

[ThomasToka]

@classicrocker883 thx. I got it already working. Have build up a own struct. But still had to modify the settings.cpp like here in this pr. But i am fine. It works.

[thinkyhead]

Our standard has been to store dummy data for common features so EEPROM doesn't necessarily require a reset after flashing new firmware with leveling turned on. This goes for various other features as well, although we have been phasing that out somewhat with the addition of new features. Unless we're prepared to wrap all the optional things like this, let's continue to follow the general standard.

If you'd like to help with the more comprehensive refactoring of the EEPROM that includes per-feature versioning and writes a more structured format, check out my proposal at https://github.com/MarlinFirmware/Marlin/projects?type=classic

[mriscoc]

Leaving code that increases the program memory usage only to avoid an EEPROM reset after flashing a new firmware doesn't seem good to me, but maybe that could be a personal choice, especially for those with program memory space problems.

[thinkyhead]

After merging the latest, I don't see anything left in this PR that is a fix. Consider getting onboard with the feature-based EEPROM refactor. That's going to be interesting, fun, and useful. https://github.com/MarlinFirmware/Marlin/projects?type=classic

[classicrocker883]

This project last updated 3 years ago. Are there other writeups about it? Also, with ChatGPT and other variants, it should be easy to input how you want it done, and it outputs what it should be. you know, give it an example, and say "hey i want it done like this for the rest of this code" and it would save bunch of time.