[BUG] Saving large mesh (100+ points) causes Marlin to reboot and corrupt EEPROM

[hakimio]

Bug Description

Trying to save a larger than 100 points mesh to EEPROM causes Marlin to restart corrupting EEPROM.

Configuration Files

Marlin config.zip

Steps to Reproduce

1. Generate a ABL mesh with more than 100 points (ie 12x12 or bigger) (G29)
2. Try to save the mesh (M500)

Expected behavior:

The mesh should be saved successfully.

Actual behavior:

Marlin restarts corrupting the EEPROM.

Additional Information

Most likely caused by watchdog (haven't tried disabling yet). Would be nice if watchdog would be disabled when saving the mesh to EEPROM or any other kind of large amount of data.

I am using MKS Robin Nano v2 board now, the same happens with v1 as well.

[ellensp]

// Following prevents Marlin reboot when writing large mesh
// #define WATCHDOG_DURATION_8S
^^^^^^^^^^^^^^^^^^^^^
Enable this

[hakimio]

I was just planning to test it out. Would be nice if WATCHDOG_DURATION_8S was at least added to the default Configuration_adv.h config. I only found out about this setting by googling for similar issues (#20070).

[ellensp]

12x12 mesh is insane for 99.99% of users. You don't set a parameter like WATCHDOG_DURATION_8S as default when it doesn't apply to 99.99% of users

[hakimio]

I am not saying to enable it by default. I am just saying to at least add it commented out.

// #define WATCHDOG_DURATION_8S

[hakimio]

Related issue: #20449
Related PR: #20510

[hakimio]

@sjasonsmith can you look into this when you have some time?

[ellensp]

Your pr has been merged, presuming this is resolved.

[hakimio]

@ellensp the PR was for a different board which I don't use. Reopen please. And it wasn't my PR.

[ellensp]

Did WATCHDOG_DURATION_8S not fix it?

[hakimio]

It is a valid workaround but:

1. it's not a solution, but a hack,
2. It's hard to find this setting. I don't understand why you can't include it in the default config (disabled).
3. @sjasonsmith has a better solution but it's only for some specific boards. It should be applied to all EEPROM implementations.

[ellensp]

not all eeproms are that slow.

[hakimio]

Let's keep this open at least until @sjasonsmith decides if his solution should be applied to other boards.
So far it seems to be an issue with MKS Robin Nano and BTT SKR boards apart from Creality V4 which was fixed already.

[nanotuxi]

Would enabeling
#define OPTIMIZED_MESH_STORAGE // Store mesh with less precision to save EEPROM space
improve the situation? (not tested yet)

[hakimio]

@nanotuxi if you read the whole thread, you'll see that we have already found possible solutions/workarounds. We are just discussing which one should be used.

[hakimio]

@ellensp I've created a PR #21436 to address the issue.

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