[BUG] UBL with GRID_MAX_POINTS_X=15: saving mesh causes reboot

[salfter]

Bug Description

I've been getting bed leveling dialed in on my Hypercube 300. I've had UBL enabled since the start, with GRID_MAX_POINTS_X set to 10. When I increased it to 15, G29 S1 appears to start saving the mesh, but then Marlin crashes and the board reboots. I backed off GRID_MAX_POINTS_X to 14 and tried G29 S1 before probing the bed, just to verify that it would work...it did. Is there some statically-allocated resource that's getting stomped?

Configuration Files

marlin-config.zip

Steps to Reproduce

1. Enable AUTO_BED_LEVELING_UBL and set GRID_MAX_POINTS_X to 15. Build and install firmware
2. Send G29 S1 to the printer. (It's not necessary to do G29 P1 first; the bug is triggered either way.)
3. Observe that it reboots.

Expected behavior:

The bed probing results get stored to whatever nonvolatile storage your board has.

Actual behavior:

Marlin crashes and restarts.

Additional Information

If it makes any difference, my printer uses an SKR Pro 1.1 with an add-on I2C EEPROM. The EEPROM was added by commenting out FLASH_EEPROM_EMULATION in Configuration.h and by adding the following to src/pins/stm32f4/pins_BTT_SKR_PRO_V1_1.h:

//
// EEPROM plugged into I2C header
// https://www.instructables.com/id/BigTreeTech-SKR-Pro-V11-Adding-a-EEPROM/
//

#define I2C_EEPROM
#ifdef E2END
   #undef E2END
#endif
#define E2END 0x7FFF // EEPROM end address AT24C256 (32kB)

[salfter]

More testing results:

GRID_MAX_POINTS_X=14

Empty grid: saves OK.
Grid obtained by G29 P1: saves OK.
Fill out the empty spots in the grid with two iterations of G29 P3, then try saving: crashes.

[ellensp]

as a test disable #define USE_WATCHDOG, see it it still reboots
Suspect UBL is taking to long triggering watchdog timer..

[salfter]

as a test disable #define USE_WATCHDOG, see it it still reboots

No reboot. With GRID_MAX_POINTS_X=15, after probing the bed and filling in the empty spots, saving the mesh took about 5.5 seconds.

[ellensp]

defaults is 4 second timeout, in bugfix WATCHDOG_DURATION_8S was added 3 days ago 4fe1adc

[thinkyhead]

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[salfter]

Please test the bugfix-2.0.x branch to see where it stands.

I tried, but now I'm getting "TMC CONNECTION ERROR"s on startup (I use TMC2130s with SPI configuration). If I revert to the release branch, it works properly. I've reconstructed settings since the config file version changed; the configs I'm using with the bugfix branch are attached: marlin-config-bugfix.zip

[salfter]

TMC CONNECTION ERROR

...and that may have been the fault of not having TMC_USE_SW_SPI defined. Trying again...

[salfter]

The bugfix branch, with WATCHDOG_DURATION_8S defined in Configuration_adv.h, gets the job done...guess I'll be switching to it for a while.

[casterle]

I had the same issue; the bugfix branch was the solution (don't forget to #define WATCHDOG_DURATION_8S).

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