Changed settings are not stored to EEPROM when saved (STM32F401) #125

theSt33v · 2022-04-19T22:05:47Z

Describe the bug
Changed settings are not stored to EEPROM when saved.

To Reproduce
Steps to reproduce the behavior:

Change any setting
Select "Store Settings" or send gcode M500 through terminal.
Power cycle printer
All settings have reverted to firmware defaults.

Expected behavior
Changed settings should survive a power cycle after being stored.

Version (please complete the following information):
Experimental build 2.1.0.1 15Apr2022 (STM32F401).

mriscoc · 2022-04-19T23:30:55Z

Thank you for your report

mriscoc · 2022-04-20T17:37:50Z

Please try the latest version: #128

bullitt186 · 2022-04-20T21:04:19Z

Unfortunately, the Issue is still unresolved with Experimental-Ender3S1-STM32F4-20220420.

mriscoc · 2022-04-20T21:42:06Z

ok, thank you, I'll look deeper later.

rockstarbill · 2022-04-22T00:06:59Z

Just confirming, the issue persists in the latest build as well.

airs0urce · 2022-04-22T08:56:49Z

Yes, same for me, after I restart Ender 3 S1 all settings reverted to defaults

wamsuperman · 2022-04-24T03:15:26Z

I am having an issue it is storing the settings but not actually using them since newest firmware I like the toolbar but it is costing me on not being able to up my acceleration

theSt33v · 2022-04-25T13:23:22Z

I also cannot store settings with the latest build. I read on the Facebook group today that someone with an F4 board does not have this issue. It's so strange that the behavior is so inconsistent with boards that have identical hardware. Maybe the path to the EEPROM is different depending on the board, which is why the save is unsuccessful in some cases?

theSt33v · 2022-04-25T13:24:38Z

I am having an issue it is storing the settings but not actually using them since newest firmware I like the toolbar but it is costing me on not being able to up my acceleration

Are you sure that your slicer is not defining the acceleration parameters?

jeeltuss · 2022-04-25T17:51:53Z

Hello, just want to post this hoping it can help to shed light on the issue.
I was fiddling with the experimental firmware & octoprint, while I was testing the missing store of settings I used the "Reboot printer" function in Control section.
After power cycling the printer reported "M112 Printer Killed", and asked to be manually shut down.

Then the web interface of octoprint reported this:

Your printer's firmware reported an error. Due to that OctoPrint will disconnect. Reported error: EEPROM CRC mismatch - (stored) 34127 != 59449 (calculated)!

thesnarkyone · 2022-04-25T18:32:56Z

I am experiencing the same issue as well. Power cycles remove settings.

mriscoc · 2022-04-25T19:06:55Z

Hello, just want to post this hoping it can help to shed light on the issue. I was fiddling with the experimental firmware & octoprint, while I was testing the missing store of settings I used the "Reboot printer" function in Control section. After power cycling the printer reported "M112 Printer Killed", and asked to be manually shut down.

Then the web interface of octoprint reported this:

Your printer's firmware reported an error. Due to that OctoPrint will disconnect. Reported error: EEPROM CRC mismatch - (stored) 34127 != 59449 (calculated)!

Check error handling in https://github.com/mriscoc/Ender3V2S1/wiki/Octoprint

jeeltuss · 2022-04-25T19:50:13Z

Hello, just want to post this hoping it can help to shed light on the issue. I was fiddling with the experimental firmware & octoprint, while I was testing the missing store of settings I used the "Reboot printer" function in Control section. After power cycling the printer reported "M112 Printer Killed", and asked to be manually shut down.
Then the web interface of octoprint reported this:
Your printer's firmware reported an error. Due to that OctoPrint will disconnect. Reported error: EEPROM CRC mismatch - (stored) 34127 != 59449 (calculated)!

Check error handling in https://github.com/mriscoc/Ender3V2S1/wiki/Octoprint

Oh ok, I was hoping that the CRC mismatch error can give a clue on why the settings are not saved. My bad. Thanks for the link.

theSt33v · 2022-04-28T00:01:40Z

The issue still exists in the 27Apr build.

vb138 · 2022-04-28T17:07:58Z

Confirmed, I have the same problem.

bankm1 · 2022-05-03T07:20:15Z

+1 settings will not save

airs0urce · 2022-05-03T12:11:30Z

As I have access to physical machine just want to let you know if you need some details to solve this issue (photos of chips etc) I can make and send them

mriscoc · 2022-05-03T12:58:20Z

As I have access to physical machine just want to let you know if you need some details to solve this issue (photos of chips etc) I can make and send them

Thank you, I do dozens of fast tests before the release of a version. But right now, it is possible to write a G-code with all configuration parameters that can be loaded at startup.

fabiomaticus · 2022-05-05T17:21:37Z

The issue still exists in the 4 May build.

mriscoc · 2022-05-05T17:45:08Z

The issue still exists in the 4 May build.

Thanks for the feedback

vb138 · 2022-05-06T16:31:30Z

For interest, please visit https://www.th3dstudio.com/hc/downloads/unified-2-firmware/creality/creality-boards-creality/creality-ender-3-s1-pro-firmware-v24s1_301-board/ and https://github.com/th3dstudio/UnifiedFirmware/commits/2.0.x

jeeltuss · 2022-05-07T13:10:01Z

For interest, please visit https://www.th3dstudio.com/hc/downloads/unified-2-firmware/creality/creality-boards-creality/creality-ender-3-s1-pro-firmware-v24s1_301-board/ and https://github.com/th3dstudio/UnifiedFirmware/commits/2.0.x

I am currently running the TH3D Unified fimware on my S1 (non Pro) with the STM32F401 chip, and I can confirm that all settings I tried are correctly saved when power-cycling the printer. Maybe this can help @mriscoc in investigating the issue.

theSt33v · 2022-05-07T17:20:36Z

I did a little bit of investigation and I think I need to clarify the issue. The settings are, in fact, stored correctly. If you save settings to EEPROM and then restore default settings, you can easily restore your previously-saved settings. This may indicate that the issue is not that the settings are not saved, but rather they are being wiped at boot.

mriscoc · 2022-05-07T17:51:57Z

I did a little bit of investigation and I think I need to clarify the issue. The settings are, in fact, stored correctly. If you save settings to EEPROM and then restore default settings, you can easily restore your previously-saved settings. This may indicate that the issue is not that the settings are not saved, but rather they are being wiped at boot.

Yes, the issue is with the calculus of the CRC EEPROM value in the F4 chips. TH3D sources are based on Marlin 2.0.9.3, the Professional sources are based on Marlin BugFix 2.1.0.0 that is why the differences.

mriscoc · 2022-05-07T19:26:32Z

If someone is confident with coding and compiling the firmware and has the F4 board, try to do tests with DEBUG_EEPROM_READWRITE enabled, check these relevant parts of the source:

Ender3V2S1/Marlin/src/HAL/STM32/eeprom_bl24cxx.cpp

Lines 72 to 82 in c2744e0

    
           bool PersistentStore::read_data(int &pos, uint8_t *value, size_t size, uint16_t *crc, const bool writing/*=true*/) { 
        
             do { 
        
               uint8_t * const p = (uint8_t * const)pos; 
        
               uint8_t c = eeprom_read_byte(p); 
        
               if (writing) *value = c; 
        
               crc16(crc, &c, 1); 
        
               pos++; 
        
               value++; 
        
             } while (--size); 
        
             return false; 
        
           }

Ender3V2S1/Marlin/src/libs/crc16.cpp

Lines 25 to 32 in c2744e0

    
           void crc16(uint16_t *crc, const void * const data, uint16_t cnt) { 
        
             uint8_t *ptr = (uint8_t *)data; 
        
             while (cnt--) { 
        
               *crc = (uint16_t)(*crc ^ (uint16_t)(((uint16_t)*ptr++) << 8)); 
        
               for (uint8_t i = 0; i < 8; i++) 
        
                 *crc = (uint16_t)((*crc & 0x8000) ? ((uint16_t)(*crc << 1) ^ 0x1021) : (*crc << 1)); 
        
             } 
        
           }

Ender3V2S1/Marlin/src/module/settings.cpp

Lines 1693 to 1694 in c2744e0

    
           uint16_t stored_crc; 
        
           EEPROM_READ_ALWAYS(stored_crc);

and

Ender3V2S1/Marlin/src/module/settings.cpp

Lines 2610 to 2616 in c2744e0

    
           else if (working_crc != stored_crc) { 
        
             eeprom_error = true; 
        
             DEBUG_ERROR_MSG("EEPROM CRC mismatch - (stored) ", stored_crc, " != ", working_crc, " (calculated)!"); 
        
             TERN_(DWIN_LCD_PROUI, LCD_MESSAGE(MSG_ERR_EEPROM_CRC)); 
        
             TERN_(HOST_EEPROM_CHITCHAT, hostui.notify(GET_TEXT_F(MSG_ERR_EEPROM_CRC))); 
        
             IF_DISABLED(EEPROM_AUTO_INIT, ui.eeprom_alert_crc()); 
        
           }

theSt33v · 2022-05-07T20:39:48Z

There's not enough flash space to enable that for the F4 without cutting other things. I'm trying to disable some features to make room but I'm running into compile errors because the features are "required for proui." I'll keep at it, but if you know any features I can cut without breaking things too much, that would be helpful.

mriscoc · 2022-05-07T21:26:44Z

Comment out in dwin_defines.h the line #define ProUIex 1
That will give you flash space.

theSt33v · 2022-05-07T22:09:53Z

Doing that caused build errors, but I was able to get a successful and functional build by disabling M503 in configuration.h, setting HAS_GCODE_PREVIEW to 0 in proui.h and commenting out the error if for HAS_GCODE_PREVIEW in dwin_defines.h. I'll see what I can find out with this CRC problem.

Could you give me some more background on what is known so far about the problem? How do we know that the issue is CRC calculation related? So far, I haven't been able to trigger any of the CRC errors.

jeeltuss · 2022-05-07T22:41:42Z

Doing that caused build errors, but I was able to get a successful and functional build by disabling M503 in configuration.h, setting HAS_GCODE_PREVIEW to 0 in proui.h and commenting out the error if for HAS_GCODE_PREVIEW in dwin_defines.h. I'll see what I can find out with this CRC problem.

Could you give me some more background on what is known so far about the problem? How do we know that the issue is CRC calculation related? So far, I haven't been able to trigger any of the CRC errors.

As I was saying here, I had octoprint reporting errors from the printer regarding crc mismatch.
I remember saving settings straight from the printer after modifying any of them (i.e. the z offset), while octoprint was connected. Hope this helps.

mriscoc · 2022-05-08T00:05:35Z

As I was saying here, I had octoprint reporting errors from the printer regarding crc mismatch. I remember saving settings straight from the printer after modifying any of them (i.e. the z offset), while octoprint was connected. Hope this helps.

Yes, you were in the correct way.

mriscoc · 2022-05-08T00:08:10Z

Of course, it is possible to disable the crc checking but it could be dangerous, but maybe it is a simple test to check if only the crc is the problem.

Ender3V2S1/Marlin/src/module/settings.cpp

Line 2610 in c2744e0

else if (working_crc != stored_crc) {

else if (0) {

theSt33v · 2022-05-08T00:10:13Z

I just did that and it is indeed the problem. If you change eeprom_error=true to false, settings are preserved after power cycle.

mriscoc · 2022-05-08T00:12:10Z

So, now we need to understand why only for the F4 is working_crc != stored_crc

theSt33v · 2022-05-08T00:13:28Z

Right. Your code in that section is the same as Creality source, and stock firmware does not have this issue, so it's very strange.

mriscoc · 2022-05-08T00:15:30Z

Creality source is based on STM32 Maple I think, that uses a different HAL implementation. The Marlin bugfix branch has deprecated the Maple version and uses STM libraries.

theSt33v · 2022-05-09T22:07:46Z

I did a lot of poking around and I only ever get that CRC error at boot. All other commands that trigger CRC checks (M500 and M501) are always successful and return CRC values that are consistent and change when they're supposed to. Even when I disable the automatic factory reset (M502) that the error usually triggers, the CRC checks pass. This means that even when you do literally nothing to the flash after the apparent corruption detected by the first check, the CRC checks pass after boot.

It seems to me that only the CRC check that happens at boot is problematic, and it's a false positive. Is there a different section of code that governs the CRC check at boot? Are the working_crc and/or stored_crc values incorrectly assigned at boot due to an incorrect hardcoded value somewhere in the settings, but correctly assigned when triggered post-boot? I don't know, but I'm going to just disable the error in the builds that I use. I'd like to get to the root of this, but I think I've reached the limit of my very limited ability to diagnose this stuff. All I can say is all the relevant sections of code that were posted earlier are nearly identical to their equivalent sections in the TH3D unified firmware (which doesn't suffer from this issue), so I don't think the problem is there.

mriscoc · 2022-05-10T05:08:15Z

But why does that error only occur for the F4 SoC? Unfortunately, I don't have an F4 board to do debugging.
From your tests I can summarize:
M500 Save data to EEPROM and store a correct calculated (working) CRC
M501 Read data from EEPROM and the stored CRC is equal to calculated (working) CRC
M997 (Reboot) triggers the error working_crc != stored_crc, but what CRC is bad? the working, the stored, or both?

theSt33v · 2022-05-10T12:03:27Z

That's correct. As for which one is bad, it wasn't consistent in my testing. One of them always matched the CRC from before the reboot (which makes it the correct one), but sometimes it was working and sometimes it was stored. I'll do more systematic tests today to see if there is a pattern.

UPDATE: In all of my testing so far, stored_crc is the correct value. I thought I saw cases yesterday where working_crc was correct, but I cannot replicate that today. I think "why only F4" is a good question to ask. That means the problem may be with code that is F4-specific and could have an effect on CRC calculations. I think another helpful question would be what action is happening at boot that results in a CRC check? Is it a read or write operation?

mriscoc · 2022-05-16T04:01:41Z

Fixed in the last release candidate version #128 (comment)

vb138 · 2022-05-16T12:23:06Z

Tested. Now all settings are preserved even after rebooting the device. Thank you.

mriscoc · 2022-05-16T15:53:22Z

Tested. Now all settings are preserved even after rebooting the device. Thank you.

Thank you for your confirmation. I'm closing the issue now.

github-actions · 2023-04-25T02:01:16Z

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.

mriscoc closed this as completed Apr 20, 2022

mriscoc reopened this Apr 20, 2022

mriscoc added the bug: Confirmed Something isn't working, the bug was confirmed. label Apr 26, 2022

mriscoc closed this as completed May 10, 2022

mriscoc reopened this May 10, 2022

mriscoc mentioned this issue May 14, 2022

Support for Ender 3 S1 with the STM32F401RCT6 SoC #128

Closed

mriscoc closed this as completed May 16, 2022

github-actions bot locked and limited conversation to collaborators Apr 25, 2023

Changed settings are not stored to EEPROM when saved (STM32F401) #125

Changed settings are not stored to EEPROM when saved (STM32F401) #125

Comments

theSt33v commented Apr 19, 2022

mriscoc commented Apr 19, 2022

mriscoc commented Apr 20, 2022

bullitt186 commented Apr 20, 2022

mriscoc commented Apr 20, 2022

rockstarbill commented Apr 22, 2022

airs0urce commented Apr 22, 2022

wamsuperman commented Apr 24, 2022

theSt33v commented Apr 25, 2022

theSt33v commented Apr 25, 2022

jeeltuss commented Apr 25, 2022 • edited Loading

thesnarkyone commented Apr 25, 2022

mriscoc commented Apr 25, 2022

jeeltuss commented Apr 25, 2022

theSt33v commented Apr 28, 2022

vb138 commented Apr 28, 2022

bankm1 commented May 3, 2022

airs0urce commented May 3, 2022 • edited Loading

mriscoc commented May 3, 2022 • edited Loading

fabiomaticus commented May 5, 2022

mriscoc commented May 5, 2022

vb138 commented May 6, 2022

jeeltuss commented May 7, 2022

theSt33v commented May 7, 2022

mriscoc commented May 7, 2022 • edited Loading

mriscoc commented May 7, 2022 • edited Loading

theSt33v commented May 7, 2022

mriscoc commented May 7, 2022

theSt33v commented May 7, 2022 • edited Loading

jeeltuss commented May 7, 2022

mriscoc commented May 8, 2022 • edited Loading

mriscoc commented May 8, 2022 • edited Loading

theSt33v commented May 8, 2022

mriscoc commented May 8, 2022

theSt33v commented May 8, 2022

mriscoc commented May 8, 2022

theSt33v commented May 9, 2022 • edited Loading

mriscoc commented May 10, 2022 • edited Loading

theSt33v commented May 10, 2022 • edited Loading

mriscoc commented May 16, 2022

vb138 commented May 16, 2022

mriscoc commented May 16, 2022

github-actions bot commented Apr 25, 2023

jeeltuss commented Apr 25, 2022 •

edited

Loading

airs0urce commented May 3, 2022 •

edited

Loading

mriscoc commented May 3, 2022 •

edited

Loading

mriscoc commented May 7, 2022 •

edited

Loading

mriscoc commented May 7, 2022 •

edited

Loading

theSt33v commented May 7, 2022 •

edited

Loading

mriscoc commented May 8, 2022 •

edited

Loading

mriscoc commented May 8, 2022 •

edited

Loading

theSt33v commented May 9, 2022 •

edited

Loading

mriscoc commented May 10, 2022 •

edited

Loading

theSt33v commented May 10, 2022 •

edited

Loading