[BUG] AUTO_BED_LEVELING_BILINEAR save anything to EEPROM does not work with 8x8 or bigger

[ThomasToka]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

During development i discovered the following odd bug:

When you create a AUTO_BED_LEVELING_BILINEAR build with 8x8 or bigger eeprom saving does not work anymore.

I made this test with a Ender 3 S1 Pro with the Encoder display from the v2 and #define DWIN_CREALITY_LCD_JYERSUI.

There is not one line of code in this project that was changed in marlin code. Configurations attached.

Bug Timeline

new to me

Expected behavior

saving to eeprom is present after reboot of the printer.

Actual behavior

Send: M851 Z2
Recv: ok P15 B7
[...]
Send: M851
Recv:   M851 Probe Offset X-31.50 Y-41.80 Z2.00 ; (mm)
Recv: ok P15 B7
[...]
Send: M500
Recv: echo:Settings Stored (876 bytes; crc 60006)
Recv: //action:notification Settings Stored
Recv: //action:notification Settings Stored
Recv: ok P15 B7

after reboot:

Send: M851
Recv:   M851 Probe Offset X-31.50 Y-41.80 Z0.00 ; (mm)

Steps to Reproduce

compile marlin bugfix-2.1.x in its actual state.

• activate AUTO_BED_LEVELING_BILINEAR with GRID_MAX_POINTS_X 5

do M851 Z2; M500 -> reboot printer M851 shows 2

• activate AUTO_BED_LEVELING_BILINEAR with GRID_MAX_POINTS_X 8

do M851 Z2; M500 -> reboot printer M851 shows 0

as a counterprobe i did the same with UBL and tested up to 10x10 mesh. everything works as exepected. eeprom save works.

Version of Marlin Firmware

bugfix-2.1.x

Printer model

Ender 3 S1 Pro

Electronics

stock

Add-ons

none

Bed Leveling

ABL Bilinear mesh

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configurations.zip

[ThomasToka]

#define DWIN_CREALITY_LCD // Creality UI
and
#define DWIN_LCD_PROUI // Pro UI by MRiscoC

do the same. btw.

my fork with a lcd does also the same.

so i think it has nothing todo with the lcd/tft/display.

[classicrocker883]

I have also noticed the same thing. ABL / Bilinear bed leveling does not save after reboot. It should like Manual Mesh and UBL, but haven't been able to get it to save to eeprom.

when first starting, going to edit the mesh values it says Mesh Invalid as well.

[ellensp]

Cannot replicate in Simulator with basic Config

[ThomasToka]

what is see in some cases if i connect fast enough:

thats what i see if i connect fast enough:

Recv: echo:EEPROM Initialized
Recv: //action:prompt_end
Recv: BL24CXX Check succeeded!

i tracked it down to

bool MarlinSettings::load() {
    if (validate()) {
      const EEPROM_Error err = _load();
      const bool success = (err == ERR_EEPROMNOERR);
      TERN(EXTENSIBLE_UI, ExtUI::onSettingsLoaded(success));
      return success;
    }
    reset();
    #if ANY(EEPROM_AUTO_INIT, EEPROM_INIT_NOW)
      (void)save();
      SERIAL_ECHO_MSG("EEPROM Initialized");
    #endif
    return false;
  }

but why?

[ThomasToka]

I did also the same with a precompiled @mriscoc professional UBL (sorry for pulling you in here mr. mriscoc). set it to 9x9.

althought it has a different approach to save some variables and it is ubl compiled it has the same problem.

after reboot everything is resetted and i am unable to save any variables to eeprom. they save fine. but after reboot -> reset.

edit: interesting is here: 8x8 works. it saves. if you then switch to 9x9, do the mesh, save, reboot -> 8x8 mesh is shown.

in my test with stock marlin 8x8 abl did not work. ubl worked completely up to 10x10.

[ThomasToka]

i´ll dump what i have written on the discord here also. as maybe someone of you did not read it there:

what i have done so far:

- activating the eeprom readwrite and observe debug -> nothing visible
- increasing write delay in the eeprom file from (2) to (8)
- debug headers for the variables in settings.cpp to check the offset -> also nothing visible on reset read or write
- looked through several pr that were about eeproms problems with big meshes. all seems included.
- tried #define WATCHDOG_DURATION_8S

what makes me curious is why ubl works up to 10x10 with way more data to save and bilinear not.

[mriscoc]

I did also the same with a precompiled @mriscoc professional UBL (sorry for pulling you in here mr. mriscoc). set it to 9x9.

althought it has a different approach to save some variables and it is ubl compiled it has the same problem.

after reboot everything is resetted and i am unable to save any variables to eeprom. they save fine. but after reboot -> reset.

edit: interesting is here: 8x8 works. it saves. if you then switch to 9x9, do the mesh, save, reboot -> 8x8 mesh is shown.

in my test with stock marlin 8x8 abl did not work. ubl worked completely up to 10x10.

I think that you saved the UBL mesh but forgot to save settings (M500). These are two separate EEPROM areas, the settings area saves the slot and the number of mesh points (M500), and the mesh area where the mesh data is stored (G29 S0). So, if you change the size of the mesh or slot number you need to save not only the mesh, but also the settings.

[ThomasToka]

I did it over the display.

-create mesh 8x8, press save on the mesh site
-store settings on the display.
-reboot
-mesh 8x8 is visible

then
-set 9x9 on the display
-create mesh and save on the mesh site
-store settings on the display
-reboot
-mesh 8x8 is still visible

did nothing with terminal here -in the case of your fork- if you mean this.

EDIT: Interestingly it works with the professional firmware abl build.

EDIT2: Now it also worked for the first time for the UBL build and 9x9. strange. but i had done the 9x9 directly after firmware installation.

EDIT3: Now it works with your fork @mriscoc but thats what i expected to be honest as you do your own routine.
I tested this tonight repeateadly with professional firmware and that what i wrote came out. Til i switched to abl and then back. strange everything.

EDIT4: Went now back to stock marlin and the problem still is the same like initially reported.

[classicrocker883]

Recv: echo:EEPROM Initialized
Recv: //action:prompt_end
Recv: BL24CXX Check succeeded!

also I received a similar error regarding the eeprom version. which is V87 or something can't remember top off my head. but can that be related, having different eeprom versions. it says something that the version should be updated everytime settings.cpp is changed.

funny you should mention watchdog because that's what was suggested here for a similar problem shadow578#37 (comment)

[ThomasToka]

But well this should not be needed if i install a stock marlin @classicrocker883 ;)

I would understand if on makes updates and then a eeprom reset is needed if the contents change. But after the "one" reset everything should be savable that is in settings.cpp declared to be saved.

Edit: For the sake of testing i changed the #define EEPROM_VERSION "V88" to #define EEPROM_VERSION "V89". changed nothing. problem persists.

[ellensp]

are you literally doing a M851 Z2; M500 as one line as in this format everything after the ; is a comment, ie M500 is not executed

[ThomasToka]

are you literally doing a M851 Z2; M500 as one line as in this format everything after the ; is a comment, ie M500 is not executed

no. it just was a sumarized short example..

in the "Actual behavior" you see what i do. each separate.

[ThomasToka]

you only need to compile a stock marlin enable bilinear with 9 grid_max_points_x.

connect with terminal.

sent
M851 Z2
sent
M500

reboot printer.
look with
M851

[ellensp]

I don't have this board, so tried with stock creality_v4 (same eeprom) only changing #define MOTHERBOARD from provided configs and GRID_MAX_POINTS_X 8 on second test... still cannot replicate...

[ThomasToka]

please try 9. i had the hiccup tonight that professional firmware worked with 8.

and dont forget to:

#define EEPROM_SETTINGS       // Persistent storage with M500 and M501
//#define DISABLE_M503        // Saves ~2700 bytes of flash. Disable for release!
#define EEPROM_CHITCHAT       // Give feedback on EEPROM commands. Disable to save PROGMEM.
#define EEPROM_BOOT_SILENT    // Keep M503 quiet and only give errors during first load
#if ENABLED(EEPROM_SETTINGS)
  #define EEPROM_AUTO_INIT    // Init EEPROM automatically on any errors.
  #define EEPROM_INIT_NOW     // Init EEPROM on first boot after a new build.
#endif

[ThomasToka]

  #define IIC_BL24CXX_EEPROM                      // EEPROM on I2C-0
  #if ENABLED(IIC_BL24CXX_EEPROM)
    #define IIC_EEPROM_SDA                    PA11
    #define IIC_EEPROM_SCL                    PA12
    #define MARLIN_EEPROM_SIZE                0x800  // 2Kb (24C16)
  #elif ENABLED(SDCARD_EEPROM_EMULATION)
    #define MARLIN_EEPROM_SIZE                0x800  // 2Kb
  #endi

thats how the eeprom itsself is in the pins file. so the configuration looks the same compared to the V4.

[ellensp]

I used provided configs... difficult to forget what you have already set

[ThomasToka]

the configs i posted here are the stock configs for the Ender S1 with only the GRID_MAX_POINTS_X changed.

besides this i did not change anything. not one file from bugfix-2.1.x download.

[ThomasToka]

i just went back in my fork (as i have older sources for it and the problem is the same as in stock) to the 07. April 2023. there the problem reproducible already exists.

but at that time i had no 10x10 builds for abl. so i even not noticed this.

so it is nothing "new" that we have here..

probably was under the radar.

[ThomasToka]

just to gather some data and document:

i now installed a marlin 2.0.8 build from creality adjusted BILINEAR to GRID_MAX_POINTS_X 9.

the problem is already there.

so it will have been under the radar for years.

[ThomasToka]

i was now able to catch it with pronterface at is connects way faster so i see the CRC_MISMATCH:

echo: Free Memory: 50295  PlannerBufferBytes: 2048
Field: e_factors
Field: home_offset
Field: runout_sensor_enabled
Field: probe_offset
Field: planner_leveling_active
Field: servo_angles
Field: bltouch_od_5v_mode
Field: bltouch_high_speed_mode
Field: ui_material_preset
Field: lpq_len
Field: power_monitor_flags
Field: lcd_contrast
Field: lcd_brightness
Field: controllerFan_settings
Field: recovery_enabled
Field: fwretract_settings
Field: parser_volumetric_enabled
Field: tmc_stepper_current
Field: tmc_hybrid_threshold
Field: tmc_sgt
Field: tmc_stealth_enabled
Field: planner_extruder_advance_K
Field: motor_current_setting
Field: coordinate_system
Field: fc_settings
Field: backlash_distance_mm
Field: dwin_data
Field: sound_on
Error:EEPROM CRC mismatch - (stored) 29591 != 57892 (calculated)!
//action:notification Err: EEPROM CRC
//action:notification Hardcoded Default Settings Loaded
echo:Hardcoded Default Settings Loaded
Field: e_factors
Field: home_offset
Field: runout_sensor_enabled
Field: planner_autotemp_max
Field: probe_offset
Field: planner_leveling_active
Field: servo_angles
Field: bltouch_od_5v_mode
Field: bltouch_high_speed_mode
Field: ui_material_preset
Field: hotendPID
Field: lpq_len
Field: bedPID
Field: chamberPID
Field: power_monitor_flags
Field: lcd_contrast
Field: lcd_brightness
Field: controllerFan_settings
Field: recovery_enabled
Field: fwretract_settings
Field: parser_volumetric_enabled
Field: tmc_stepper_current
Field: tmc_hybrid_threshold
Field: tmc_stealth_enabled
Field: planner_extruder_advance_K
Field: motor_current_setting
Field: coordinate_system
Field: fc_settings
Field: backlash_distance_mm
Field: dwin_data
echo:Settings Stored (916 bytes; crc 16565)
//action:notification Settings Stored
echo:EEPROM Initialized
//action:prompt_end
BL24CXX Check succeeded!
echo:SD card ok
echo: Serial 0 baud rate set to 250000

@ellensp

now i will add headers again.. cause i never saw the first part.. will come back with them soon ^^

[ThomasToka]

ok i was not able to track it down. but i have done a further counter probe and can say that my

LPC1768 aka #define MOTHERBOARD BOARD_BTT_SKR_V1_3

does not have the problem. everything works like it should.

there it is:

Send: M420V1
Recv: Bilinear Leveling Grid:
Recv:       0      1      2      3      4      5      6      7      8
Recv:  0 +0.077 +0.087 +0.058 +0.043 +0.067 +0.092 +0.133 +0.125 +0.120
Recv:  1 +0.072 +0.063 +0.055 +0.038 +0.060 +0.115 +0.137 +0.145 +0.113
Recv:  2 +0.072 +0.050 +0.035 +0.053 +0.070 +0.103 +0.135 +0.153 +0.145
Recv:  3 +0.067 +0.058 +0.040 +0.040 +0.055 +0.095 +0.110 +0.125 +0.107
Recv:  4 +0.092 +0.063 +0.048 +0.048 +0.030 +0.095 +0.137 +0.147 +0.115
Recv:  5 +0.063 +0.053 +0.053 +0.045 +0.058 +0.123 +0.167 +0.183 +0.125
Recv:  6 +0.055 +0.087 +0.058 +0.043 +0.075 +0.100 +0.157 +0.167 +0.145
Recv:  7 +0.080 +0.065 +0.048 +0.063 +0.063 +0.125 +0.140 +0.170 +0.145
Recv:  8 +0.082 +0.067 +0.060 +0.060 +0.095 +0.120 +0.145 +0.163 +0.173

and aditionally: it can not be my board only that is faulty, as i gave my 10x10 builds to several users and none of them could save to eeprom with it.

[thisiskeithb]

Can you reproduce this on the original board if you add a #define SDCARD_EEPROM_EMULATION (be sure to insert an SD card for this to work) or #define FLASH_EEPROM_EMULATION to your config?

This may highlight something related to IIC_BL24CXX_EEPROM.

[ThomasToka]

i am poking around this everywhere..

[EvilGremlin]

could be just bad eeprom chip, change it

[ThomasToka]

could be just bad eeprom chip, change it

have dozens of users that confirmed this.

[EvilGremlin]

both STM and GD?

[ThomasToka]

i am running a fork for the ender 3 s1 pro and have meanwhile over 250 users on my discord. so a good testing base.

but this also happens with stock marlin as i wrote. and my test for this here was made with stock marlin and a encoder display.

[EvilGremlin]

point about changing eepriom chip (to different brand) still stands, will narrow it down a lot

[ThomasToka]

if you add a #define SDCARD_EEPROM_EMULATION

japp this works @thisiskeithb

[thisiskeithb]

japp this works

I assumed as much since you had no issues with the SKR 1.3 and that also has an emulated EEPROM.

[ThomasToka]

both STM and GD?

  for 2.0.8
  #if ENABLED(USER_STM32F103)
    #define MOTHERBOARD BOARD_CREALITY_S1
  #elif ENABLED(USER_STM32F401)
    #define MOTHERBOARD BOARD_CREALITY_S1_F401RC
  #endif

  or in 2.1.x
  #define MOTHERBOARD BOARD_CREALITY_V24S1_301F4
  #define MOTHERBOARD BOARD_CREALITY_V24S1_301

  

Those two i have among my users. but 95% this: MOTHERBOARD_CREALITY_S1_F401RC/MOTHERBOARD BOARD_CREALITY_V24S1_301F4 i think.

[ThomasToka]

ok... after the whole day of reducing settings.cpp.

i have a result. i have it saving now with a 10x10 mesh and BILINEAR.

basically i reduced eeprom saving by those unneeded fields in my case.

I removed some fields in

typedef struct SettingsDataStruct

and later reads and writes..

it saves. on the way i saw also some reboots when the debug was on..

what i now did was:

Disabling MESH_BED_LEVELING Fields (9 dummies):

  **#if ENABLED(MESH_BED_LEVELING)**
  float mbl_z_offset;                                   // bedlevel.z_offset
  uint8_t mesh_num_x, mesh_num_y;                       // GRID_MAX_POINTS_X, GRID_MAX_POINTS_Y
  uint16_t mesh_check;                                  // Hash to check against X/Y
  float mbl_z_values[TERN(MESH_BED_LEVELING, GRID_MAX_POINTS_X, 3)]   // bedlevel.z_values
                    [TERN(MESH_BED_LEVELING, GRID_MAX_POINTS_Y, 3)];

  **#endif**

Disabling Coordinate Fields:

    **#if ENABLED(CNC_COORDINATE_SYSTEMS)**
    xyz_pos_t coordinate_system[MAX_COORDINATE_SYSTEMS]; // G54-G59.3
    **#endif**

Disabling backlash fields:

  #if NUM_AXES
   **//** xyz_float_t backlash_distance_mm;                   // M425 X Y Z
   **//** uint8_t backlash_correction;                        // M425 F
   **//** float backlash_smoothing_mm;                        // M425 S

And after i disabled TMC it started to save again:

  **//**per_stepper_uint16_t tmc_stepper_current;             // M906 X Y Z...
  **//**per_stepper_uint32_t tmc_hybrid_threshold;            // M913 X Y Z...
  **//**mot_stepper_int16_t tmc_sgt;                          // M914 X Y Z...
  **//**per_stepper_bool_t tmc_stealth_enabled;               // M569 X Y Z...

i dont know if the TMC fields are responsible or if it is just a "space" thing and the TMC fields make enough space free then.

but it works.

i will intersect tomorrow backward and enable the other functions again to see where it beginns.

besides this i have ton of debug headers in here. lol

i would highly appreciate if someone has an eye on the settings.cpp so that it matches the actual configuration.

or if we can start a discussion why some fields always are written/readen although not used.

Thank you all so far.

[ThomasToka]

the backlash fields i could activate again.

but if i activate

CNC_COORDINATE_SYSTEMS
or
the TMC fields it stops working.

crc sums that can’t be calculated correctly for those maybe?

for now i also have let the MESH_BED_LEVELING fields deactivated.

i don’t need all three.. so for me no problem. but i think for other users with STANDALONE it could be important.

will test tomorrow again.

[ThomasToka]

also MESH_BED_LEVELING enabling in settings.cpp leads to the same. i mean when using AUTO_BED_LEVELING_BILINEAR.

[mriscoc]

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

[github-actions]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.