Marlin: [BUG] settings not load on start

[satiromarra]

Description

The settings not load on start Marlin

Problem

From https://github.com/MarlinFirmware/Marlin/pull/14458

In file: Marlin/src/Marlin.cpp lines 944 to 946

#if DISABLED(SD_EEPROM_EMULATION)
   (void)settings.load();
#endif

SD_EEPROM_EMULATION is enabled in Conditionals_post.h

#if ENABLED(EEPROM_SETTINGS) && NONE(**FLASH_EEPROM_EMULATION**, SPI_EEPROM, I2C_EEPROM)
  #define SD_EEPROM_EMULATION
#endif

I have enabled EEPROM_SETTINGS in Configuration.h but in Marlin/src/HAL/HAL_LPC1768/persistent_store_api.h (line 24) FLASH_EEPROM_EMULATION is defined by default:

#define FLASH_EEPROM_EMULATION

I have to load the settings manually.
i not use sd card.

[WillThomas]

I also see this or a similar bug on a SKR 1.3. On boot all settings are overwritten to 0 if #EEPROM_SETTINGS is enabled.

octoprint log from a cold boot:
M503; to indicate that currently loaded settings are zero
M502; load hardcoded firmware settings
M500; save the settings to eeprom

M503; shows settings are still zerod out.

https://pastebin.com/jZF0rZYy

[satiromarra]

In the file Marlin/src/Marlin.cpp, comment the lines 944 and 946 works fine and the settings load correctly on start.

//#if DISABLED(SD_EEPROM_EMULATION)
(void)settings.load();
//#endif

But I do not know what other changes can be corrected or what can affect in other boards, configurations, etc ...

[ManuelMcLure]

For LPC1768 FLASH_EEPROM_EMULATION is set in src/HAL/HAL_LPC1768/persistent_store_api.h - that should be sufficient to disable SD_EEPROM_EMULATION. However, src/HAL/HAL_LPC1768/persistent_store_api.h doesn't seem to be included in a way that Marlin.cpp gets it - it's only included in src/HAL/HAL_LPC1768/persistent_store_flash.cpp and src/HAL/HAL_LPC1768/persistent_store_sdcard.cpp.
Marlin.cpp only gets src/HAL/shared/persistent_store_api.h so it doesn't know that FLASH_EEPROM_EMULATION is enabled.

[tpruvot]

same here, but for another reason... HAS_SPI_LCD is set while we use a STM32F1 FSMC for the display (which is not spi)

[satiromarra]

I use RAMPS 1.4 + REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER + 2 Extruders + NOT SD
HAS_SPI_LCD is defined in src/inc/Conditional_LCD.h:343

#define HAS_SPI_LCD          ENABLED(ULTRA_LCD)

[thinkyhead]

Sorry about the flags confusion. We're trying to fulfill a request to have a conditional that says "SD EEPROM emulation is in effect!" But the persistent store header is apparently not included as a standard element of the HAL for all Marlin code that includes MarlinConfig.h. The larger issue is that we haven't developed a standard way for HALs to insert their own conditionals.

Anyway, I'll see if I can get the HAL headers sorted so that the Conditionals_post.h also gets the persistent store header.

[thinkyhead]

same here, but for another reason... HAS_SPI_LCD is set while we use a STM32F1 FSMC for the display (which is not spi)

Does Marlin have an LCD option for that so that it knows you have an FSMC display? If so, then it just needs to handle that LCD selection properly in Conditionals_LCD.h (and in the sanity check).

[klcjr89]

This is still broken on my Azteeg X5 mini and I have no idea why. Can you please fix this? Was working perfectly two days ago..

[satiromarra]

Is it possible that this condition is incorrect? in Conditionals_post.h lines 1738 to 1740

#if ENABLED(EEPROM_SETTINGS) && NONE(FLASH_EEPROM_EMULATION, SPI_EEPROM, I2C_EEPROM)
  #define SD_EEPROM_EMULATION
#endif

Have defined EEPROM_SETTINGS in Configuration.h, but FLASH_EEPROM_EMULATION, SPI_EEPROM and I2C_EEPROM is not defined.

File Marlin.cpp lines 1099 to 1104, that condition #if ENABLED(SD_EEPROM_EMULATION) may run too late or not being inside #if !HAS_SPI_LCD ?

#if !HAS_SPI_LCD

   #if ENABLED(SD_EEPROM_EMULATION)
      SERIAL_ECHOLNPGM("Loading settings from SD");
      (void)settings.load();
   #endif
.....

[thinkyhead]

The patch that introduced the issue has been reverted. You may continue to use the latest code (with other new and interesting bugs, to be sure).

[klcjr89]

To be clear, have things been more broken lately due to adding support for all of these chinese boards?

[thinkyhead]

Nothing so topical as that. I'm going through the process of getting the HALs into a more standardized arrangement, and sorting out the #include order and dependencies is proving to be a challenge.

[tpruvot]

made that: https://github.com/tpruvot/Marlin/commit/f5f885c9b7324eeb761612023414fbbb2a3eacd0

[thinkyhead]

Thanks! I need to sleep for 5 or more hours now, but I will bring those in for testing later today.

[github-actions[bot]]

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.