Marlin: [BUG] Mesh bed levelling data lost after two power cycles

[LMF5000]

Description

Running SKR E3 DIP with manual mesh bed levelling, latest marlin 2.0.x (as of yesterday) and trinamic TMC2208 in UART mode.

Mesh bed levelling data is stored fine, retained after one power cycle, but then gets lost after the second power cycle.

The data was retained fine using a slightly older marlin 2.0.x back when the data was stored in an eeprom.dat file on the SD card.

Steps to Reproduce

1. Perform manual levelling
2. Store data
3. Turn printer off
4. Turn printer on - data is retained
5. Turn printer off
6. Turn printer on - levelling data is lost
7. Connect to serial monitor, send M501 - response "EEPROM version mismatch (EEPROM=? Marlin=V69)"

Expected behavior: [What you expect to happen]
EEPROM data retained after infinite power cycles

Actual behavior: [What actually happens]
EEPROM data lost after two power cycles

Additional Information

Did not happen in previous v2.0.x
Config.zip

[boelle]

tried clearing eeprom?

[LMF5000]

Yep, I've initialised the EEPROM via the LCD menu, twice.

I also verified that the settings are lost whether they're originally saved via the LCD menu ("store settings") or via sending gcode M500 over serial. In both cases the result is the same after 2 power cycles.

[boelle]

yeah, that is what i do... first M502 and then M500 so that settings in firmware are stored in eeprom, this also updates the eeprom version,

maybe @shitcreek or @thinkyhead can shine some light on it

[LMF5000]

Once the EEPROM data is lost, attempting to read it with M501 returns the error "EEPROM version mismatch (EEPROM=? Marlin=V69)" - maybe that holds the clue to what's happening?

[After the first power cycle M501 reads the EEPROM values properly as usual, the error only starts after the second power cycle]

[boelle]

maybe, that is why i suggested to read firmware settings and overwrite eeprom

ie first M502 to read hardcoded values, then overwrite eeprom by sending M500, and then M501 to confirm (send all 3 commands one after the other)

but if 2 powercycles after that gives the problem then something is not right

[LMF5000]

Indeed, I think this might be an oversight since Marlin switched over to EEPROM emulation on the STM32 instead of the EEPROM.dat file on the SD.

As an aside, is there a config option to go back to using the SD as EEPROM storage as it was before? Firstly this serves as a workaround to the issue, and secondly I'm not too keen to wear out the limited write cycles on the STM32's memory with EEPROM if it can be avoided.

[reloxx13]

@LMF5000 can you try this:
m851 ;get current z offset
m851 z-1.xx ;set a new offset
m500 ;save
m501 ;load

now powercycle once and see with m851 if your new offset is reverted.

[reloxx13]

you can disable it by commenting it out in the pins file

https://github.com/MarlinFirmware/Marlin/blob/665e45e0bad4254352330884a846c21aad2a2ff0/Marlin/src/pins/stm32/pins_BIGTREE_SKR_E3_DIP.h#L36-L40

[LMF5000]

I don't have a probe installed or enabled in firmware so M851 returns "unknown command: M851".
I have instead tried it with M420 Z7 (set fade height).

Results:
Input -> Output
M420 Z7 -> "Fade height 7.00"
M503 -> reports back "M420 S0 Z7.00"
M500 -> "Settings Stored (628 bytes; crc 47716)"
M501 -> "READ: echo: M420 S0 Z7.00"

Power cycle 1 (20 seconds off).

M501 -> "EEPROM version mismatch (EEPROM=? Marlin=V69)"

So this time it failed after just one power cycle. Hmm.

Thanks for posting the workaround in the pins.h file - looks like I shall be using it :).

[LMF5000]

Do I comment out just line 36 or all the lines 36-40?

[tpruvot]

only 36, E2END still required to avoid using 4KB of ram by default (which is a lot)

[tpruvot]

just to note, current marlin one is now V70, and may have new issues about Meshes... seems under work

[thinkyhead]

As an aside, is there a config option to go back to using the SD

Good question. We should formalize this as an advanced setting asap.

[LMF5000]

Yes, it would be very useful to have a line for setting eeprom location (SD or flash) in conf_adv.h instead of pins.h. Thank you for considering it 😁.

FWIW I have everything working again after disabling the eeprom emulation line as suggested above. As long as I have the SD card inserted during power-up the mesh is loaded correctly every time.

[boelle]

will close this one as it seems to be fixed

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