Printer won't store settings after BigTreeTech firmware update of 25/11/19

[Ciss0]

Hello community,

I have a SKR mini E3 v1.2, and I've been extremely satisfied with it! However, 2 days past I uploaded the new firmware.bin (supplied from bigtreetech over here) to my ender 3 and on the first impact I was extremely satisfied by the new features on the options available from the printer.

Then I noticed something was wrong, after I turn off the printer, when I turn it back on and for example use the command "PreHeat ABS" (which I configured to have PLA+ settings) it puts the defaults values. Also, I have customized E-steps and they also revert back to default when I turn off the printer...

This did not happen before on the previous versions of firmware that I installed, I tried to reinstall the firmware with no sucess, I tried to format both sdcards (I use different sd card for printing and for firmware updating) also without success.

The printer is still working, however it is very annoying that I have to re-configure it every time I turn it on...

Anyone has any input in this issue?

Cheers

[bryanhunwardsen]

There are a lot of issues with the BTT fork of marlin, its way behind marlin 2.0 bugfix.
I experienced a similar issue which most discussion indicates is an issue with eeprom storage not placed in a safe place in memory. There are other issues with serial and sd card related to this.

[brew99]

I don't use the BTT version, but it looks like they updated only a few days ago, so is similar to vanilla marlin. That being said, after you are changing a parameter on the LCD (i.e. Preheat ABS), you are required to then select "store settings" to send that to the emulated eeprom, so it will be retained after a power off. Not sure if you are doing that extra step

[Ciss0]

Yes, pretty much I assume it's something from the new BTT version. Unfortunately, I'm not proficient at all in programming, so I haven't ventured in trying to compile my own firmware, but I guess I should give it a look, or wait for BTT to upload a fixed version.

I don't use the BTT version, but it looks like they updated only a few days ago, so is similar to vanilla marlin. That being said, after you are changing a parameter on the LCD (i.e. Preheat ABS), you are required to then select "store settings" to send that to the emulated eeprom, so it will be retained after a power off. Not sure if you are doing that extra step

I always did the step of "store settings", and up until the new BTT version it was storing, only now it is not.

I'll continue search more about this!

[x0r13]

I can confirm that settings are not saved. This might lead to a fatal crash of the nozzle into the bed since Z offset is also not saved. In my case it defaults to 1.85 while my real value is .65
Neither using the menu and the "Save Settings" option or the M500 command do work (even though there is an OK message along with the CRC).

I can't even find an information if the provided image uses SD card for saving the settings or the emulated EEPROM.

[bryanhunwardsen]

I can confirm that settings are not saved. This might lead to a fatal crash of the nozzle into the bed since Z offset is also not saved. In my case it defaults to 1.85 while my real value is .65
Neither using the menu and the "Save Settings" option or the M500 command do work (even though there is an OK message along with the CRC).

I can't even find an information if the provided image uses SD card for saving the settings or the emulated EEPROM.

You should be able to tell by looking at the conf and adv conf header files, as that would be the expectation, but I cant guarantee BTT follows this practice properly and includes a binary that is not reflective of the current code state.

[x0rzist]

You can try to disable the print counter. I had the problem that the EEPROM got corrupted on every boot. There was a bug report on Marlin which I can't find right now, but disabling the print counter resolved the issue.

[goos766]

The problem is that the configuration is saved (M500) and everything looks ok when entering the M501 command but later even without restarting for some reason unknown to me the printer returns to the original configuration. Saving to the SD card, bed level points, stutters after 4 point reading after any attempt to change "original" settings. update from November 25, 2019

[lococnc]

Disable #define EEPROM_AUTO_INIT

[goos766]

Disable #define EEPROM_AUTO_INIT

is this possible using gcode commands? if it's not through gcode, I can't do anything about it because I can't compile anything using Visual Studio Code, it simply doesn't work for me on Windows 10.

[gitmiz]

I can confirm that this is an issue. Using Marlin_SKR_E3_mini_12_512K. EEPROM settings are not persistent between board cycles but M500 works. After M503 verification, sending a M501 will revert to firmware settings, not EEPROM. #define EEPROM_AUTO_INIT is disabled.

[meltonpieman]

I can confirm that this is an issue. Using Marlin_SKR_E3_mini_12_512K. EEPROM settings are not persistent between board cycles but M500 works. After M503 verification, sending a M501 will revert to firmware settings, not EEPROM. #define EEPROM_AUTO_INIT is disabled.

So are you saying we should enable #define EEPROM_AUTO_INIT and that would solve it?

[gitmiz]

No, it was suggested to do that but does not resolve. Issue is open.

[stedaho]

I can also confirm this issue, using the SKR mini E3 v1.2 with the latest firmware image from here.

[hubris123]

confirming this. After a reboot, the stored "bed leveling" and "Z offset" are gone. the M420 S1 that is sent causes this error to show on the LCD screen.
KILLED. :
PRINTER HALTED
Please reset

I have to flash the firmware to get it back up and running.

[thebest07111]

I have the same problem. it says it stores the settings(by heering the beep) and then after restart the z probe baby offset is ste to 0 again.

[hubris123]

I built one previous to the latest and it works. Enabled manual bed leveling plus a bed z offset. did a bed level, printed fine. turned it off for 10 minutes and it worked again. so it is definitely this version that lost the ability to store settings.

[smcallis77]

I also have this issue. Changes to EEPROM_AUTO_INIT and PRINTCOUNTER (the two suggestions in this thread don't seem to have resolved the problem), but I have not yet done sufficient testing due to other priorities. I have been setting the necessary configuration changes in my slicer as a workaround.

[DoctorDanke]

I can also confirm that after compiling the newest BTT fork of marlin for my SKR Mini E3 V1.2 board, that my printer loses the information stored in the emulated EEPROM, after 2 reboot cycles. If I do a manual bed leveling, and set my fade height, store the settings using the LCD, and do a complete power cycle, the first time it is fine, then on the second power cycle, it loses the EEPROM information.

Right now, as a workaround, I have had to uncomment out "#define FLASH_EEPROM_EMULATION" in Marlin\src\pins\stm32\pins_BTT_SKR_MINI_E3.h, which enables saving the EEPROM data to the SD card, which is working perfect.

[stedaho]

If I don't miss something, there are just two changes regarding flash/eeprom in the diff to the current version:

1. The definition of STM32_FLASH_SIZE moved from pins_BTT_SKR_MINI_E3.h to HAL.h (should be irrelevant)
2. The definition of EEPROM_START_ADDRESS in pins_BTT_SKR_MINI_E3.h has changed from uint32(0x8000000 + STM32_FLASH_SIZE - 2 * EEPROM_PAGE_SIZE) to uint32(0x8000000 + (STM32_FLASH_SIZE) * 1024 - 2 * EEPROM_PAGE_SIZE)

As I don't have set up a build environment here: @DoctorDanke, would you mind to remove the newly introduced factor in the EEPROM_START_ADDRESS definition (and re-enable FLASH_EEPROM_EMULATION) and test if the EEPROM data is stored persistently in the flash again?

[goos766]

I wonder why the not compiled version posted by bigtreetech is not intended for BLtouch. it could include uncompiled versions for each option of new *.BIN files. I'm not sure what options to change to connect the printer and BLtouch with confidence. either expect the nozzle to destroy/hit the surfaces of the heated bed, or assume that something unexpected will happen. I'm not sure how to connect the white and black cable, because there were two options so far. what you have to change in Marlin for each of them.

[DoctorDanke]

stedaho, you are correct, that a number of things changed with the latest version mentioning the eeprom. Right now, as long as my machine is running perfect (saving the EEPROM on the SD), I don't have the time right now to mess with things. I have a batch of TPU parts running for the next 10 hours and tomorrow I have my latest version of my product packaging needing to be printed in PLA Plus and tested for fitment (Trying to get my latest product out before Christmas). I will wait until the firmware is officially updated to try again with this mess. I use my machine way too much right now to be messing with it when it is at least working fine. Oh, BTW, this is still the best board out there (and I would buy it again in a second). I have my machine running almost constantly, and love how silent and accurate it prints after my upgrades.

[wjones1972]

2. EEPROM_START_ADDRESS
stedaho,
I have complied the firmware.bin with the changes you suggest. As soon as my print finishes about 2 hrs I will give it a test. Thanks for the suggestion..

[smcallis77]

If I don't miss something, there are just two changes regarding flash/eeprom in the diff to the current version:

1. The definition of STM32_FLASH_SIZE moved from pins_BTT_SKR_MINI_E3.h to HAL.h (should be irrelevant)
2. The definition of EEPROM_START_ADDRESS in pins_BTT_SKR_MINI_E3.h has changed from uint32(0x8000000 + STM32_FLASH_SIZE - 2 * EEPROM_PAGE_SIZE) to uint32(0x8000000 + (STM32_FLASH_SIZE) * 1024 - 2 * EEPROM_PAGE_SIZE)

As I don't have set up a build environment here: @DoctorDanke, would you mind to remove the newly introduced factor in the EEPROM_START_ADDRESS definition (and re-enable FLASH_EEPROM_EMULATION) and test if the EEPROM data is stored persistently in the flash again?

@stedaho I noticed this myself, but, the definition of STM32_FLASH size had changed from say 256 * 1024 to just 256, so the calc should still be valid. Still, something is wrong and your suggestion is a good one. I think you are suggesting - replace STM32_FLASH_SIZE with a literal 256 (or 512 as the case maybe) recompile and test. I'll see if I can find time to test it today.

[stedaho]

@smcallis77 You are right, I didn't notice that.
Than the calculation of the EEPROM_START_ADDRESS should be fine, given that the processor type is set correctly (there are three different flash sizes available according to the datasheet, comparision on page 11, memory layout on page 40). They reserve two 2 kB blocks right at the end of the flash section.

[wjones1972]

stedaho
I made the change you suggested below and it compiled without error. when loading it to the board the display comes on but I get an alarm from the board and it doesn't function I went back and commented out #define FLASH_EEPROM_EMULATION and recompiled and it works but saves the config to the sd card. Not a bad solution as long as you always use the same card. Let me know if I can try anything more as my print should be free for a while.

I also tried with differant memory sizes for example
#define EEPROM_START_ADDRESS uint32(0x8000000 + (STM32_FLASH_SIZE) * 256 - 2 * EEPROM_PAGE_SIZE)

The definition of EEPROM_START_ADDRESS in pins_BTT_SKR_MINI_E3.h has changed from uint32(0x8000000 + STM32_FLASH_SIZE - 2 * EEPROM_PAGE_SIZE) to uint32(0x8000000 + (STM32_FLASH_SIZE) * 1024 - 2 * EEPROM_PAGE_SIZE)

[brew99]

I'm using current vanilla marlin (bugfix-2.0.x from today) and enabling PRINTCOUNTER in configuration.h causes the emulated EEPROM to be wiped on reboot (or second reboot). Disabling Printcounter allows the settings to remain after a reboot. I don't normal set anything via the LCD, so didn't realize this was an issue, but sure enough, it isn't working as intended.

Has anyone reported this on Marlin github? I can only see a closed issue, which didn't really in my mind address it, and/or confirm it was a fix

edit: found an open issue

[wjones1972]

brew99,

I can confirm your results if comment out PRINTCOUNT in configuration.h and recompile and flash it to my board. Then my setting will persist through several power cycles.

[smcallis77]

I also agree. With PRINTCOUNT defined saved settings are lost after the second power cycle. At least it was the second cycle for me twice today.

After undefining PRINTCOUNT as the only change and reflashing I have been able to power cycle 5 times so far with no loss of saved settings.

Apologies to @x0rzist who identified the issue as a PRINTCOUNT problem 6 days ago.

[gitmiz]

Commenting out PRINTCOUNTER does not actually resolve the original issue. Prior to last update, EEPROM was able to be saved to MCU memory, as intended. After update, EEPROM config must again be saved to SD Card by commenting out #define FLASH_EEPROM_EMULATION. Regardless of PRINTCOUNTER define, EEPROM config written to MCU flash is lost upon board power cycle. Issue is still open.

[crysxd]

I had the same issue with the precompiled firmware in this repository. I found the problem is fixed when the latest vanilla Marlin with the BTT configuration from this repository is compiled.

As I imagine setting up the environment is challenging for some and I want to update my printer regularly, I set up nightly builds of the vanilla Marlin with the BTT configuration in my fork. You can download a daily compiled firmware.bin on the release page (listed under "Assets").

[sillyturdle]

I set up nightly builds of the vanilla Marlin with the BTT configuration in [my fork]

Thank you for this. This is the easiest solution I could find, plus having the config files already working out of the gate makes it nice to customize. You're the best!!!

[ToXIc69]

ok my head hurts from all the reading and reflashing over and over in the last three days. i just got v1.2 E3 bord and cant save any changes. Ive tried compiling the following versions
-Marlin 2.0.5 - had to do the z noise fix
-Marlin Bugfix-2.0.x
-BIGTREETECH SKR-mini-E3
but still have the issues with it not saving babysteps etc. i cant even move the Z with the offset option in the menus. even with the already compiled .bim file from BTT's repo.
Printcounter doesnt seem to fix it.
here are the options i change with vanilla marlin 2.0

• #define BLTOUCH
• DEFAULT_MAX_FEEDRATE { 500, 500, 15, 25 }
• NOZZLE_TO_PROBE_OFFSET { -45, -7,-1.8 }
• MIN_PROBE_EDGE 20
• XY_PROBE_SPEED 10000
• Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 2)
• GRID_MAX_POINTS_X 3
• #define Z_SAFE_HOMING
• HOMING_FEEDRATE_XY (40*60)
• HOMING_FEEDRATE_Z (20*60)
• #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
• Z_MIN_PROBE_ENDSTOP_INVERTING true
• //#define AUTO_BED_LEVELING_BILINEAR
• #define MESH_BED_LEVELING
• #define LCD_BED_LEVELING
• adv.h
• BABYSTEP_MULTIPLICATOR_Z 10

[ToXIc69]

I had the same issue with the precompiled firmware in this repository. I found the problem is fixed when the latest vanilla Marlin with the BTT configuration from this repository is compiled.

As I imagine setting up the environment is challenging for some and I want to update my printer regularly, I set up nightly builds of the vanilla Marlin with the BTT configuration in my fork. You can download a daily compiled firmware.bin on the release page (listed under "Assets").

sir do i download your fork and use the BTT config files from the marlin repo?
https://github.com/MarlinFirmware/Configurations/archive/release-2.0.5.zip

[AalianKhan]

@ToXIc69 hey don't stress out, BigTreetech did make it confusing more than it should be. Download the source code for the latest release from @crysxd fork (https://github.com/crysxd/Marlin/releases). It's under assets. Then change it to your needs. so define bltouch and other things you want to add. If you get stuck don't hesitate.

[ToXIc69]

in his fork i downloaded i dont see the config_adv.h or the config.h files
if i use the one from BTT i get errors stating its older and also a mismatch an option because the name changed.
if i use the filed from vanilla for BTT same issue i cant save.

edit: is the fils in the Marlin folder already the correct one for the E3 lemme look
edit2: crap i dont know how to tell lol

[AalianKhan]

@ToXIc69 yup those are correct. Just change them to your needs and compile/upload the firmware

[crysxd]

@ToXIc69 the files in BTT repository are very old and broken. Do this:

• Download and flash this file. It is the latest Marlin (not to 2.0.5 but all latest changes) with a working configuration. Don't compile it yourself, you might do something wrong.
• Adjust baby steps
• Make sure to select "Store settings" in the menus. All changes you make are only temporary if you do not select store settings after.
• Restart printer and check if values are stored.

If this is working you can try to compile your own firmware.bin with changes you like.

Moving the Z offset did not work for some weeks because of a bug I think. I had the same issue and it was fixed very recently.

Are you using a BLtouch?

[ToXIc69]

@crysxd yes sir i'm using BLTouch and the follwoing

#define BLTOUCH
DEFAULT_MAX_FEEDRATE { 500, 500, 15, 25 }
NOZZLE_TO_PROBE_OFFSET { -45, -7,-1.8 }
MIN_PROBE_EDGE 20
XY_PROBE_SPEED 10000
Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 2)
GRID_MAX_POINTS_X 3
#define Z_SAFE_HOMING
HOMING_FEEDRATE_XY (4060)
HOMING_FEEDRATE_Z (2060)
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
Z_MIN_PROBE_ENDSTOP_INVERTING true
//#define AUTO_BED_LEVELING_BILINEAR
#define MESH_BED_LEVELING
#define LCD_BED_LEVELING
adv.h
BABYSTEP_MULTIPLICATOR_Z 10

ive tried compiling your fork with the config_adv.h or the config.h file in it but having the same problems. I ABL before every print and it just wipes the baby Z steps from the last print . its not stooring anything to the eprom.

edit: i did see in your config.h file you have PrintCounter defined should that be undefined?

[crysxd]

Use the precompiled firmware.bin first. It won't have BLtouch but you can see if you can store settings. Check this first. If this works I can assist you with BLtouch.

[ToXIc69]

ok

edit: getting a 404 error at the link
edit2: downloaded testing

[ToXIc69]

what settings can i change.. most of em are blocked because i cant home all axis.

[crysxd]

Go to Menu > Configuratrion > Probe Z offset and chnage the value. Press the button, scroll down and select "Store Settings". Restart the printer and see whether the value at Menu > Configuratrion > Probe Z offset was stored. No homing needed.

[ToXIc69]

thats the setting i was looking for it doesnt show up because its not homed.
video clip of going trough the menus. https://streamable.com/arwmd

so in config, advanced, auto temp.
i turned it On and set min to 200.
saved
powered off / on
went back to Off and min of 210
didnt save :/

[leokabayashi]

Someone has commited a change to bugfix branch 16h ago. Comment: "Tweak eeprom storage type"
MarlinFirmware/Marlin@54a12ee

Not sure if this solves or changes anything regarding what is being discussed in the thread.

BTW, I have the same issue, installed skr mini e3 v1.2 and bl-touch but loses Probe Z-offset after 2 power cycles.

edit: I have never compiled a Marlin firmware from scratch, but I'm considering doing this later today.

[leokabayashi]

Go to Menu > Configuratrion > Probe Z offset and chnage the value. Press the button, scroll down and select "Store Settings". Restart the printer and see whether the value at Menu > Configuratrion > Probe Z offset was stored. No homing needed.

After using your latest precompiled firmware I was not able to follow these instructions, I think Probe Z-offset disappears since your firmware does not have BL touch enabled.

[crysxd]

Sorry! This absolutely true @leokabayashi. I have a tweaked version on my printer with bltouch support. But you can also use the setting @ToXIc69 used to test wether everything is stored to eeprom.

@ToXIc69 you can try the buodl of bugfix-2.0.x tomorrow, it will include the commit mentioned above. Is this does not work as well it's best to open a ticket in Marlinfirmware/Marlin repository

[ToXIc69]

ok will try the new release.

another weird thing is that i did a
M851 Z0
M500
M501 - setting stayed.
power cycled
M501 - setting still there
did a print saved the baby z step.
retried print and zstep didnt stay

[crysxd]

You mean you executed m851 or m501 again at the end and z was not 0 anymore?

[ToXIc69]

no i did the m501 to read and it was still 0

but look like it may just be z baby steps it doesnt want to save. i'll print, adjust the babystep save via menu and also M500 from octoprint restart the same print from scratch and the babystep is gone and it prints high again. here is my gcode ive been using for years
; Ender 3 Custom Start G-code
G28 ; Home all axes
G29 ; BLTouch mesh generation
G92 E0 ; Reset Extruder
G1 Z2.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed
G1 X0.1 Y20 Z0.3 F5000.0 ; Move to start position
G1 X0.1 Y200.0 Z0.3 F1500.0 E15 ; Draw the first line
G1 X0.4 Y200.0 Z0.3 F5000.0 ; Move to side a little
G1 X0.4 Y20 Z0.3 F1500.0 E30 ; Draw the second line
G92 E0 ; Reset Extruder
G1 Z2.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed
; End of custom start GCode

gonna try calibrating the E and see if that stays.

[crysxd]

Can you do

M851 Z0
M501
G28
M501

Maybe homing resets it? I know that g28 can break the mesh, maybe that's part of it. Not sure though.

[ToXIc69]

no the offset value stayed.
i also calibrated the E and save the value cycled power and it kept that value also.

so now i'm clueless.. it is saving values just not saving the babyZ i guess i'll make a new thread .

thx for the help.

[Topless-Stang]

Sorry! This absolutely true @leokabayashi. I have a tweaked version on my printer with bltouch support. But you can also use the setting @ToXIc69 used to test wether everything is stored to eeprom.

@ToXIc69 you can try the buodl of bugfix-2.0.x tomorrow, it will include the commit mentioned above. Is this does not work as well it's best to open a ticket in Marlinfirmware/Marlin repository

Any way you can post up the one you have with BLTouch enabled? I checked your repo & the ones there do not have BLTouch. I am currently without a means to compile my own. Thanks!

[crysxd]

You have a standard printer and only bltouch? Let me see if I find time today or tomorrow to prepare a version for you. My tweaked one also has other stuff like a custom extruder.

[Topless-Stang]

You have a standard printer and only bltouch? Let me see if I find time today or tomorrow to prepare a version for you. My tweaked one also has other stuff like a custom extruder.

Yes sir, for the most part. Aluminum Extruder (top), btt tft 35, e3d v6 & octopi...but I believe from a FW standpoint its pretty vanilla besides BL Touch. Will be printing and swapping in a new mount/shroud this weekend but I don't think that will make a difference. Anything you could do to help me out would definitely be appreciated.

[crysxd]

@Topless-Stang Please download this firmware and follow the steps in the readme. Please be cautions, I did not test this build. Please open an issue here to give me feedback. Daily builds will be setup on the weekend.

If anyone else has questions about my repository, please use the issue system there and do not highjack this issue here :)

[leokabayashi]

BigTreeTech firmware file bas been updated a few days ago, does anybody know if it solves this issue anyhow?

Edit: Answering my own. question: apparently it did not: 4ec12ab#commitcomment-38608226

[Daz-jones]

If you switch from tft to marlin mode (TFT35) and save it, stores to the eprom with no issues on cold boot.