[BUG] DATA STORED IN FLASH EEPROM DOES NOT PERSIST MORE THAN ONE POWER OFF/ON/OFF CYCLE AFTER AN M500[BUG] (short description)

[Thinkersbluff]

Bug Description

My Configurations

MyConfigs.zip

Steps to Reproduce

1. Power-On the system
2. Set Fade Height to a non-zero value (e.g. 10), on the Bed Leveling menu.
3. Use Manual Bed Leveling, to store at least one non-zero mesh data point.
4. Select "Store Settings".
5. Change Fade Height to a different value (e.g. 9).
6. Use "Edit Mesh" to modify any mesh value (e.g. X0, Y0)
7. Select "Load Settings".
8. Verify Fade Height changes back to the value set at step 2.
9. Verify the modified mesh value is restored to the value stored at step 3.
10. Power-Off the system
11. Power-On the system
12. Auto-Home or G28 the system
13. Verify the Fade Height is the value stored at step 2.
14. Verify the modified mesh value is the value stored at step 3.
15. Power-Off the system.
16. Power-On the system.
17. If you have reproduced this "BUG", then the Fade Height value and all of the Mesh values will once again be Zero.
18. Repeat steps 1-9.
19. Select "Store settings" or issue an M500 command.
20. Power-Off the system.
21. Repeat steps 11 to 14. If you have reproduced the "work around" for this bug, steps 13 and 14 will pass correctly.

Expected behavior: [What you expect to happen]
I expect all of the data I store in EEPROM to be restored every time Power is turned back ON, regardless of how many times I cycle Power OFF/ON, after I originally store that data. I do not expect to have to deliberately store that data every time, before I turn Power off.

Actual behavior: [What actually happens]
If "Store Settings" is selected on the Bed Leveling menu, after creating mesh data or after setting a non-zero value for Fade Height, then power is turned OFF/ON, the data is restored (which is correct).
If the power is then cycled OFF/ON again, without first issuing a second Store Settings (M500) command, the data stored is not restored (this behaviour appears to be a bug.)
If, instead, the Store Settings menu is selected or an M500 code is issued, before cycling Power OFF, then the originally stored values are again restored, as they should be, when Power is turned back ON.

Additional Information

• I am observing these issues with the 11 Dec release of Marlin 2.0.x, on an SKR Mini E3 v1.2.
• When I comment-out the line "#define FLASH_EEPROM_EMULATION" in the file pins_BTT_SKR_MINI_E3.h, then Marlin 2.0.x reverts to using the SD card to store EEPROM.dat. In that configuration, the EEPROM does work as expected.

[thisiskeithb]

I am observing these issues with the 11 Dec release of Marlin 2.0.x, on an SKR Mini E3 v1.2.

Can you try with the latest bugfix-2.0.x release to see if your issue persists?

[tpruvot]

bullshit, too much caps

[Thinkersbluff]

Sorry, thisiskeithb.
I am a total NOOB with Marlin and with PLATFORMIO/VISSTUDIO. I am having trouble compiling a firmware.bin with the 11 Jan 2020 Marlin 2.0.xbugfix...

I first tried copy/pasting my Configuration.h and Configuration_adv.h files into the Marlin folder of the 11 Jan 2020 Marlin2.0.xbugfix and compiling with the platformio.ini environment set to default_envs = STM32F103RC_bigtree_NOUSB, as I do for the 11 Dec 2019 version. That compile failed with, Error: Unknown environment names 'STM32F103RC_bigtree_NOUSB'. Valid names are ..."

I tried changing the environment name to STM32F103RC_bigtree_USB, but once I got past the other issues, the compiler said the resulting firmware was not going to fit in memory.

I did succeed compiling a firmware.bin, using the evironment name STM32F103RC_bigtree, after updating Configuration_adv.h in response to the following two errors from SanityCheck.h:
"#error "FILAMENT_UNLOAD_RETRACT_LENGTH is now FILAMENT_UNLOAD_PURGE_RETRACT. Please update Configuration_adv.h."
"#error "FILAMENT_UNLOAD_DELAY is now FILAMENT_UNLOAD_PURGE_DELAY. Please update Configuration_adv.h."
I also added the line "#define FILAMENT_UNLOAD_PURGE_FEEDRATE 25 // (mm/s) feedrate to purge before unload" which I found in the GitHub version of Configuration_adv.h for this release.

Now my compile succeeds, but throws the following two cautions:

"Compiling .pio\build\STM32F103RC_bigtree_USB\src\src\lcd\dogm\u8g_fontutf8.cpp.o
Marlin\src\lcd\dogm\status_screen_DOGM.cpp: In function 'void _draw_bed_status(bool)':
Marlin\src\lcd\dogm\status_screen_DOGM.cpp:238:16: warning: unused variable 'isHeat' [-Wunused-variable]
const bool isHeat = BED_ALT();
^~~~~~"

"Compiling .pio\build\STM32F103RC_bigtree\libb84\USBComposite\Joystick.cpp.o
C:\Users\think.platformio\packages\framework-arduinoststm32-maple\STM32F1\libraries\STM32ADC\src\utility\util_adc.c:10:30: warning: 'adc_result' initialized and declared 'extern'
extern volatile unsigned int adc_result = 0;
^~~~~~~~~~"

I tested the new firmware.bin in my Ender 3 and can confirm that this bug has been corrected.
Only anomaly this time was that firmware.bin was NOT renamed to FIRMWARE.CUR, so leaving the SD card in the machine during the test forced a reflash of the firmware which cleared the EEPROM, causing the test to fail. Easy fix, when issue is known, but may signal some other issue with 2.0.1?

Many thanks also to sjasonsmith for his comment below, which arrived while I was updating this one.
Yes, good guess, I was trying to run the printer counter, which was not working. Totally forgot about that, while fighting other issues with the 3D printer...
I will update the Thingiverse Ender 3 Group thread with this info also, hopefully avoiding similar feedback from others not running 2.0.1.

[sjasonsmith]

It sounds like you are missing this fix which is in 2.0.1 (NOT 2.0):

#16118

I’m on my phone so can’t check your configs easily, but I am guessing you have print counters enabled, which will write to the flash every time you turn on the printer. This was corrupting the flash contents prior to this fix.

[Thinkersbluff]

NOTE: Sorry for "SHOUTING"...
All caps in the bug title was not my deliberate choice. I thought the form forced that on me.
Does the form include some tagging around the placeholder text that I might have used in ignorance?
Pls. try not to scare noobs who report bugs in good faith. Everybody is just trying to be helpful. Some of us may accidentally irritate the more experienced.
The rules of conduct here are wise but not always observed...

[Thinkersbluff]

Exactly right, Jason. Thank you for your quick & helpful response. I have updated the bug thread with what I learned. I was caught off-guard by a PlatformIO environment name change for the SKR E3 mini at 2.0.1. Hoping I guessed correctly which one to use. I have noted two cautions thrown by the compiler, in case they need further attention. I won’t “risk” raising a bug report on those points, since firmware.bin did compile anyway. Reported bug now fixed. New issue for me was that firmware.bin was not renamed after the flash, so the flash kept repeating on each power cycle until I removed the SD card. Again, no plan to report as a BUG, but noted in case it actually is significant. Thank you for all you do to help our community. Cheers, spj From: Jason Smith <notifications@github.com> Sent: January 11, 2020 1:02 PM To: MarlinFirmware/Marlin <Marlin@noreply.github.com> Cc: Thinkersbluff <badback42@outlook.com>; Author <author@noreply.github.com> Subject: Re: [MarlinFirmware/Marlin] [BUG] DATA STORED IN FLASH EEPROM DOES NOT PERSIST MORE THAN ONE POWER OFF/ON/OFF CYCLE AFTER AN M500[BUG] (short description) (#16532) It sounds like you are missing this fix which is in 2.0.1 (NOT 2.0): #16118<#16118> I’m on my phone so can’t check your configs easily, but I am guessing you have print counters enabled, which will write to the flash every time you turn on the printer. This was corrupting the flash contents prior to this fix. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#16532?email_source=notifications&email_token=AIW3WXSGDVFZBV7N3U45R6TQ5ICRRA5CNFSM4KFQHW22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWHQZI#issuecomment-573339749>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIW3WXUWEOQ5Z6NL7LVVBH3Q5ICRRANCNFSM4KFQHW2Q>.

[sjasonsmith]

@Thinkersbluff, thanks for letting us know it now works. Could you close the issue now that it is resolved?

I have noted two cautions thrown by the compiler, in case they need further attention. I won’t “risk” raising a bug report on those points, since firmware.bin did compile anyway.

There are always some warnings caused by some of the external libraries. I mostly recall seeing them in LCD and NeoPixel libraries. Those are safely ignored. Ideally Marlin would not generate warnings in its own code, but it can be hard to get everything right with so many possible combinations.

[Thinkersbluff]

Bug fixed at 2.0.1, ref: #16118<#16118>

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