[EEPROM_INIT_NOW] Need better understanding of functionality and possible homing defect?

[just-trey]

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

Yes, and the problem still exists.

Bug Description

This may be a feature request not sure. When flashing a new build onto my machine I have enabled EEPROM_INIT_NOW as when I first load the new configuration it freezes on the boot screen unless I turn this on. After screen calibration and the UI loads if I try to home I get a

Homing failed, Printer halted, Please reset

I power cycle the printer the issue will repeat itself unless I go and Reset the EEPROM in the advanced settings menu.

Bug Timeline

not sure i think EEPROM_INIT_NOW is a new value or it moved

Expected behavior

After flashing the firmware, the EPROM intis, and homing works without having to reset the EEPROM again. after

Actual behavior

After initial flashing the EEPROM seems to init but what I go home the bed I get a "Homing failed, Printer halted, Please reset " message

Steps to Reproduce

1. Build and install firmware
2. boot the machine to load the firmware.
3. Run through the screen calibration
4. Try to home the machine once the interface is available.

Version of Marlin Firmware

2.0.9.3

Printer model

Elegoo Neptune 2

Electronics

Stock ZNP Robin Nano 1.3 (MKS Robin Nano 1.3 clone)

Add-ons

BLTOUCH

Bed Leveling

ABL Bilinear mesh

Your Slicer

Other (explain below)

Host Software

Other (explain below)

Additional information & file uploads

Slicer and host software do not apply to this issue.

Configuration.zip

[ellensp]

//#define EEPROM_INIT_NOW // Init EEPROM on first boot after a new build.
Ie each and every time you compile and upload marlin updates the eeprom back to defaults in firmware.
Its new.To stop users updating firmware values and not updating eeprom so the old values are still used. (as they are in eeprom)

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

• MarlinFW.org Marlin Documentation
• RepRap.org Marlin Forum
• Facebook Group "Marlin Firmware"
• Facebook Group "Marlin Firmware for 3D Printers"
• Marlin Configuration on YouTube
• 3D Printing Discord server. Join link: https://discord.gg/qNnSzsug
• Marlin specific Discord server. Join link: https://discord.gg/n5NJ59y

After seeking help from the community, if the consensus points to a bug in Marlin, then you should post a bug report.

[Vertabreak]

i would like to add in testing of this new feature given its description i had assumed it would auto initialize the eeprom on first boot. this is not the behavior observed it prevents any movement and results in kill if you try until you manually clear the eeprom after flashing. it is unclear if this behavior is intended or not as it does prevent the user from getting in to a situation where old settings get loaded.

[ellensp]

#23276
I haven't checked it since it was re-written...

[ellensp]

If it prevents any movement like claimed... that is a bug...

[Vertabreak]

no movement can happen till you manually clear the eeprom your self. if you try move it calls kill.
i have tested it on a mega2560 in case its just on some boards.

[thinkyhead]

if you try move it calls kill

See if there's any helpful message when POSTMORTEM_DEBUGGING is enabled. Also, it may help to enable MARLIN_DEV_MODE and reboot the board while connected to a serial monitor, as this will print out each step in the setup() process.

[mikeww1]

I can confirm this bug on a SKR 2. The Eeprom is not reset when this parameter is activated.

[just-trey]

I am willing to to test in my board
too (mks_robim_nano35) if a fix is proposed.

[thinkyhead]

I posted a request for more information above. Please refrain from "me too" posts on confirmed bugs.

[ellensp]

Some debugging + additional echos to tell me where it is in the code and the status of some flags at that time (all start with ?)

00:49:44.824 > start
00:49:44.824 > echo:[0] HAL_init()
00:49:44.825 > echo:[1] esp_wifi_init()
00:49:44.826 > Marlin bugfix-2.0.x
00:49:44.826 > echo: Last Updated: 2022-01-03 | Author: (none, default config)
00:49:44.829 > echo: Compiled: Jan 6 2022
00:49:44.830 > echo: Free Memory: 5435 PlannerBufferBytes: 1136
00:49:44.832 > echo:[8] ui.init()
00:49:44.833 > echo:[9] ui.reset_status()
00:49:44.834 > echo:[10] settings.first_load()
00:49:44.835 > echo:?MarlinSettings::load()
00:49:44.837 > echo:?MarlinSettings::validate()
00:49:44.838 > echo:?MarlinSettings::validating set true
00:49:44.840 > echo:?MarlinSettings::_load()
00:49:44.841 > echo:?Hash mismatch (EEPROM=304358519 Marlin=304361851)
00:49:44.844 > echo:?MarlinSettings::_load returned: 1
00:49:44.845 > echo:?MarlinSettings::validating set false
00:49:44.847 > echo:?MarlinSettings::_load()
00:49:44.848 > echo:?Hash mismatch (EEPROM=304358519 Marlin=304361851)
00:49:44.851 > echo:?MarlinSettings::_load returned: 1
00:49:44.853 > echo:[28] thermalManager.init()
00:49:44.857 > echo:[32] print_job_timer.init()
00:49:44.858 > echo:[34] endstops.init()
00:49:44.859 > echo:[35] stepper.init()
00:49:44.860 > echo:[36] watchdog_init()
00:49:44.862 > echo:[37] setup() completed.

So the hash mismatch is being identified
but MarlinSettings::reset() is not called.
so when it calls _load() again it is still in error and just drops out of _load without loading settings.

_load is always returning true so validate also returns true

So in MarlinSettings::load the reset() and save() is never called

 bool MarlinSettings::load() {
    DEBUG_ECHO_MSG("?MarlinSettings::load()");
    if (validate()) {
      const bool success = _load();
      DEBUG_ECHO_MSG("?MarlinSettings::_load returned: ",success);

      TERN_(EXTENSIBLE_UI, ExtUI::onConfigurationStoreRead(success));
      return success;
    }
    reset();
    #if EITHER(EEPROM_AUTO_INIT, EEPROM_INIT_NOW)
      (void)save();
      SERIAL_ECHO_MSG("EEPROM Initialized");
    #endif
    return false;
  }

A eeprom version miss match is the only thing that gets to the reset

[mriscoc]

MarlinSettings::reset() is not called in Ender3v2 with STM32F1 stock 4.2.2 board after firmware update if EEPROM_INIT_NOW is enabled. In this case, also it is not possible to do a home because all the configuration variables are in 0. This confirm that the configuration variables were not initialized with the default values. Loading the default values fixes it.

In settings.cpp, bool MarlinSettings::_load() returns true if stored_hash and build_hash are different.

[rzblue]

Can also confirm, default ender 3 pro configuration on SKR mini e3 v2.0. Enabling this feature prevents homing and calls kill(). It also prevents movement on G0/G1. Resetting EEPROM did not seem to fix the issue, although I did not do extensive testing.

[rowbotik]

I’m encountering this as well. Ran into the same fix, homing causes a halt unless I manually reset the EEPROM. SKR Mini E3 v2.0 on a CR10-S with an z-probe.

[thisiskeithb]

Fixed in #23479

[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.