Unable to write the combination of mesh, PID settings and e-steps to EEPROM with values from printer menu

marsmol80 commented 2 years ago

Issue

Unable to write the combination of mesh, PID settings and e-steps to EEPROM with values from printer menu

Description

I am unable to write the combination of mesh, PID-tuning and e-steps to EEPROM. Storing the individual setting or any combination of 3 of them works fine. As soon as I try to write all four, in any order, the EEPROM gives out. The issue is present only when I have used the saved output of auto-tuning and done e-step definition via the printer menu. If I manually set the PID values via the terminal and enter e-steps via M92 everything works fine. Doing bed levelling via printer menu is not a problem.

Issue that might be related

:bangbang: When I change the bed-I or the bed-D via the printer menu, the value gets written to the hotend-I or hotend-D :bangbang: I think this is also what happens in #35 , which is about the amz_melzi_bed-2.0.9.2-kad1. As I see the same issue on amz2_btt_mini-2.0.9.2-kad-1, I think it is generic. Have created #42 for this.

Printer configuration

Firmware: amz2_btt_mini-2.0.9.2-kad-1 Printer: Mega Zero 2.0 Board: SKR Mini MZ v1.0

Settings I try to write to EEPROM

bed levelling 9-point mesh (result of levelling routine)
result of hot end PID tuning (result of auto-tuning saved to RAM)
result of bed PID tuning (result of auto-tuning saved to RAM)
new value for e-steps (manual entry via menu)

Result

The printer restarts.
The display says eeprom version error
Octoprint at some point showed an eeprom datasize error
Either resetting, ignoring and initialising the eeprom all get the printer working again, but with all settings gone.

kad commented 2 years ago

If you changed drastically between versions of firmware, you need to reset/initialize from defaults EEPROM. Once initalized, apply your customisation settings (e.g. e-steps, re-calibrate bed manual mesh, custom pid). On that stage, saving should work properly.

marsmol80 commented 2 years ago

Resetting/initializing EEPROM does not solve the issue.

kad commented 2 years ago

It shouldn't be affecting such, but some people reported in upstream marlin that it was fixed by replacing SD card. Otherwise, I'd suggest to file bug in upstream: https://github.com/MarlinFirmware/Marlin

kad commented 2 years ago

@marsmol80 I've got some new ideas based on what I've seen changes in upstream bugfix branch and recently released 2.0.9.3:

can you try "maple" builds? it might be so that EEPROM functionality was broken with STM32 HAL, but not with older maple based STM32F1 HAL.
preliminary builds of 2.0.9.3 are now available: http://orava.kad.name/3d/2.0.9.3-kad1/ you can try and check if problem still persist (I hope not...)

kad commented 2 years ago

I think all of this related to EEPROM issue in 2.0.9.2 for STM32 HAL. Not visible in maple variant. Please upgrade to 2.0.9.3.

marsmol80 commented 2 years ago

Sorry to not have responded sooner. I think your analysis was correct. Now that I am on 2.0.9.3. I no longer see any weird behaviour related to the EEPROM.

kad commented 2 years ago

@marsmol80 great! thanks for confirmation!

kad / Marlin