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.

[wjones1972]

gitmiz Commenting out PRINTCOUNTER does fix the issue.. With that removed the setting will store to the EEPROM I can confirm my settings for z offset and filament setting persist after several power cycles even with no SD card in the printer. for some reason the printcounter is corrupting the EEPROM or something

[smcallis77]

Commenting PRINTCOUNTER also fixes the issue for me. Since replacing #define PRINTCOUNTER with //#define PRINTCOUNTER, I can make changes to at least Z OFFSET and extruder esteps using M92 (haven't tried anything else). Saving with M500 makes these settings persistent across at least 10 power cycles so far. This is reproducible. PRINTCOUNTER is corrupting the EEPROM storage. As stated by @brew99 the issue with PRINTCOUNTER has been raised in the marlin repo at least twice that I have found so far. The issues have been closed with no fix only workarounds. Note: using the eeprom.dat file on the SD card by commenting out FLASH_EEPROM_EMULATION is also another suitable workaround. I have no need for print stats so for me at least commenting PRINTCOUNTER is more elegant.

[brew99]

Some more discussion on Marlin Github

[gitmiz]

Well, it doesn't work for me. I'm using the latest firmware from BTT, not Marlin vanilla. What platformio.ini environment are you using? I'm using default_envs = STM32F103RC_bigtree_512K

[smcallis77]

@gitmiz, sorry it's not working for you. It;s been working fine for me for the last few days - approx 20 power cycles; I am using the same environment setting as you.

Board version 1.2, BLTouch configured as Z_END_STOP, firmware size based on my configured options 229KB default_envs = STM32F103RC_bigtree_512K

It is definitely reproducible for me . uncomment PRINTCOUNTER, recompile, upgrade firmware - settings are not persistent across power cycles. comment PRINTCOUNTER, recompile, upgrade firmware - no more issues.

Have you tried with 256K? It's possible that some of the RC variant chips cannot support the 512K. I might be just lucky. I am not even sure I have an RC chip (haven't checked) as apparently some of the V1.2 boards were shipped with the RE version.

[gitmiz]

I guess it's entirely possible however unlikely that my particular MCU has some bad sectors above 256K. v1.2 board as well with RCT. My compiled firmware.bin is approx 284K.

I do wish I could save eeprom to flash but saving to SD card isn't so bad. It is odd that the culprit in the precompiled BTT firmware appears to be printcounter yet it makes no difference on my board. I only enabled the usuals in config; s-curve accel, tmc debug, ubl, etc. Didn't touch anything unfamiliar. Makes no sense.

[JPCossu]

Hello, same problem for me, I killed my bed last night following the update with the firmware bltouch for Z homing. I am desperate, I do not know how to compile a firmware to apply one of the solutions (Printcount or backup in the SD card). Do you know if Bigtreetech will publish a fix? I'm looking for a bltouch for Z homing already compiled. Sorry for my poor english (google trad). Best regards

[bryanhunwardsen]

For anyone having this issue... What I have found in the last couple weeks. I thought 512k was not working for me, I had serial connection issues, I had eeprom issues. Slowly but surely they all came down to bad configuration on my part. First though, I'm not using BTT, I'm using latest (well from about 5-7 days ago from marlin 2.0 bugfix master, not using skr sample config either. I am using default cfg's that I went through section by section, line by line, and only modified the bare minimum requirements for the board/printer. Everything worked. Then I added every be and whistle I could imagine, bl touch, sensorless homing etc etc. 280k image on 512 definition. Everything worked still. I even tested print counter vs z offset /eeprom stability without issue. I can't say how or why BTT image/cfg is messed up, but main/master with just fine. I know that doesn't help people who don't understand how to configure and complete. However, this IS the state of 3d printing, time to learn. Good luck. If it is really that bad I'll fill master this weekend and do a few simple cfg's to get newbs back online.

[JPCossu]

if that can bring me a solution thank you very much Bryan ;)

[tatusah]

The EEPROM issues that were caused by printcounter have now been fixed with pull request https://github.com/MarlinFirmware/Marlin/pull/16118 merged to the Marlin bugfix-2.0.x branch and it will be included in the upcoming 2.0.1 release expected this weekend. Even with the fix using the printcounter will eventually wear out the flash at it has limited number of times it can be written data with (shouldn't be a problem in normal use). Still, because the statistics from the printcounter probably isn't that important feature for most of the user it will be disabled by default in the future config examples.

I've tested the EEPROM fix pull request and it also solved issues that made it impossible to save things like z-offset and UBL meshes in certain situations. Without the fix those values would be lost when turning of the printer. With the fix everything works now as expected. So I would either recommend compiling new firmware from the Marlin bugfix branch or wait for the 2.0.1 release.

[Ryanmaturi]

Guess I'll just leave my printer on for now, I am assuming this knocks out my pid tune and estep values. I have a bondtech.

[tatusah]

Guess I'll just leave my printer on for now, I am assuming this knocks out my pid tune and estep values. I have a bondtech.

Just connect to the printer and use G-code M503 S0 to output settings in a format that's easy to copy-paste for restoring the settings after flashing new firmware. That makes flashing new versions a lot less hassle.

[Ryanmaturi]

Could I have octoprint issue the set commands on connection?

[The-slunk]

The serial ports were flipped on the 1.0 version from the old configuration.h file, and the current Marlin 2.0.x BTT example config. Could it be an issue with sending the M501 command to the wrong port?

[brew99]

BTT needs to update their version to the current bugfix-2.0.x and all should be ok. Or try commenting out PRINTCOUNTER

Sent from my iPhone

On Dec 16, 2019, at 4:20 PM, The-slunk notifications@github.com wrote:

 The serial ports were flipped on the 1.0 version from the old configuration.h file, and the current Marlin 2.0.x BTT example config. Could it be an issue with sending the M501 command to the wrong port?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Ryanmaturi]

looked around for a precompiled fimrware cause i hate platform IO and it was a pain in the past. this time it was easy. here is a BIN for anyone who wants it. only change from BTT is commented out print counter, which i could care less about. https://drive.google.com/open?id=1RvAlshwbnEwnOk-5Q3W5Tn0dWeZlygrW

[stricko37]

I just upgraded to the latest precompiled firmware and am having the same problem with the settings not saving to eeprom... Will this be fixed soon? I'll give Ryan's firmware a go tomorrow I guess...

[Mc-Tommy]

Does anyone knows why big tree tech is not addressing this issue? It is there for a while and not saving settings is not a small bug. Is Ryan's file working?

[hubris123]

its been an issue since the end of November. I haven't seen a company just disregard such a big issue before. currently, I have one running but can't do anything more with it until this is resolved because I don't want to put in tons of settings like manual bed mesh numbers over and over.

It would be nice to find out when this will be fixed.

[brew99]

Put in a Pull Request (to //Printcounter), or even better yet learn how to use VSCode w/ platformio. Manipulate your own firmware based off Marlin bugfix-2.0.x, and you will have control and not rely on BTT to update the firmware

[hubris123]

@brew99 FYI it's not helpful to post things like this at all. I program in multiple languages, but it's not my product and not my job to fix something I purchased and has had a massive bug since I received it.

BTW the Printcounter fix did not work for everyone. And yes I tried it. If you had bothered to read the thread I have posted tests between versions I have built.

There is always 1 person like you that decides to post this same BS thing. Please refrain from doing so in the future it literally helps no one.