-
-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changed settings are not stored to EEPROM when saved (STM32F401) #125
Comments
Thank you for your report |
Please try the latest version: #128 |
Unfortunately, the Issue is still unresolved with Experimental-Ender3S1-STM32F4-20220420. |
ok, thank you, I'll look deeper later. |
Just confirming, the issue persists in the latest build as well. |
Yes, same for me, after I restart Ender 3 S1 all settings reverted to defaults |
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 |
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? |
Are you sure that your slicer is not defining the acceleration parameters? |
Hello, just want to post this hoping it can help to shed light on the issue. Then the web interface of octoprint reported this:
|
I am experiencing the same issue as well. Power cycles remove settings. |
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. |
The issue still exists in the 27Apr build. |
Confirmed, I have the same problem. |
+1 settings will not save |
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. |
The issue still exists in the 4 May build. |
Thanks for the feedback |
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. |
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. |
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
Ender3V2S1/Marlin/src/libs/crc16.cpp Lines 25 to 32 in c2744e0
Ender3V2S1/Marlin/src/module/settings.cpp Lines 1693 to 1694 in c2744e0
and Ender3V2S1/Marlin/src/module/settings.cpp Lines 2610 to 2616 in c2744e0
|
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. |
Comment out in dwin_defines.h the line |
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. |
Yes, you were in the correct way. |
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 (0) { |
I just did that and it is indeed the problem. If you change eeprom_error=true to false, settings are preserved after power cycle. |
So, now we need to understand why only for the F4 is |
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. |
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. |
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. |
But why does that error only occur for the F4 SoC? Unfortunately, I don't have an F4 board to do debugging. |
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? |
Fixed in the last release candidate version #128 (comment) |
Tested. Now all settings are preserved even after rebooting the device. Thank you. |
Thank you for your confirmation. I'm closing the issue now. |
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. |
Describe the bug
Changed settings are not stored to EEPROM when saved.
To Reproduce
Steps to reproduce the behavior:
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).
The text was updated successfully, but these errors were encountered: