[BUG] Crash when Saving Settings

[Doormat1]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

When I change something like my z offset value mid print, if I save the change to eeprom using the save settings command on the menu it causes my printer to restart and loads up the firmware values rather than the previous eeprom values.
I am using an skr mini e3 v2 board and have used the bugfix code.

Bug Timeline

New

Expected behavior

Values are saved and the printer continues on

Actual behavior

Printer restarts and loads firmware values not eeprom

Steps to Reproduce

Babystep the printers first layer,
click save settings,
printer dies.

Version of Marlin Firmware

Bugfix 2.0.x

Printer model

Ender 3 pro

Electronics

SKR Mini E3 v2

Add-ons

No response

Bed Leveling

ABL Linear grid

Your Slicer

Cura

Host Software

OctoPrint

Additional information & file uploads

Marlin.zip

[rstalde]

The same problem temporaly exists with my Ender 5 with BTT SKR mini E3 V2.
The error occurs preferably when the height of the hot end is changed by microstepping and saved.
BTT-E5.zip

[Doormat1]

Like to see its not just me then!

[thinkyhead]

For some extra output when loading / saving EEPROM, define in your configuration:

#define DEBUG_EEPROM_READWRITE
#define EEPROM_CHITCHAT

Then you can connect via serial console, change some settings, and try M500 to save settings and M501 to load the saved settings. The extra output may give some indication where the crash is occurring. If you see mismatches, that will also give a hint where problems may exist. You might also play around with M502 and M503 to see if there are any strange values when resetting or reporting the settings.

[rstalde]

Hello everyone.
Attached the log and the current configuration files
Hardware used:
Ender 5
SKR mini E3 V2.0
TFT 35 V3.0 E3

Displaymode: Marlin Text

Action:
SD card in port of mainboard

Z-Leveling with wizard to set the offset of the BL-Touch > Successful
Save the setting > Logged crash, then all data on default values in the program

Error with high probability so reproducible (occurred here with 4 of 5 attempts)

Other variant, which does not create however more the message for logging:
Displaymode: BTT Graphic

Action:
SD card in the card reader of the display

Start print job
Wait for heating up
Change distance 0.02 mm via microstep during bed leveling and save. Repeat 3 times directly one after the other until the Busy Message appears in the display.

Printer starts after the message:
"echo:busy: processing
T:204.88 /205.00 B:60.03 /60.00 @:74 B@:25
X:243.0000 Y:220.0000 Z:6.9425 E:0.0000 Count X:19440 Y:17600 Z:5554
echo:busy: processing
//action:notification Ender-5 Ready.
T:205.06 /205.00 B:60.02 /60.00 @:69 B@:27
X:243.0000 Y:220.0000 Z:11.8500 E:0.0000 Count X:19440 Y:17600 Z:9480"
new,then all data on default values in program

Error reproducible with relative certainty (occurred here on 5 out of 5 attempts).

I hope I can help with this information in troubleshooting ;)
Marlin FM.zip

[thinkyhead]

Try building Marlin using the *_maple target and see if you get a different result from building for the non-maple target. You can use the "Auto Build Marlin" extension to more easily see the available build options. You may need to delete the .pio folder between builds to fix 'undefined symbol' errors.

[thinkyhead]

Another thing to test: If you save settings using M500 over the serial connection do you see the same issue, or only when saving settings from the LCD menu?

[thinkyhead]

I have an SKR Mini E3 V2 here but it uses the GD32F103RET6 processor, so I may not be getting the same results as you are seeing. So far, just powering the board over USB and using the config supplied by @rstalde (plus PINS_DEBUGGING and POSTMORTEM_DEBUGGING) the behavior has been … interesting. Sometimes the display draws very sluggishly, while other times it is fine. Sometimes I can see the serial port and other times it doesn't appear in the available ports list. I'm only powering over USB so perhaps that is an issue. I don't have 12V plugged into the board at the moment, so I may change settings to A4988 so it won't complain or try to talk to the stepper drivers over SPI / Serial. During an SD print that only plays tones the screen is very unresponsive. I get the sense that maybe the tone timer or the beeper pin is somehow involved, but I have nothing definitive figured out yet.

[CRCinAU]

I've had this a few times since we switched to an STM32 environment - but never had a chance to debug or gather more data.

I always save via M500 from USB - sometimes it works, sometimes it causes a response like:

Recv: echo:Error writing to EEPROM!
Recv: echo:Error writing to EEPROM!
Recv: echo:Error writing to EEPROM!
Recv: echo:Error writing to EEPROM!
Recv: echo:Error writing to EEPROM!
Recv: echo:Error writing to EEPROM!

I also have the SKR Mini E3 v2 - but not sure what chip it is - I guess the only way I can tell is via the printing on the MCU?

I don't believe this is a very recent problem - as I saw it early on after switching maple -> stm32 - but figured I'd done something weird to cause it.

[thinkyhead]

One strange symptom on this board is that when I connect to USB with a serial console the UI becomes very sluggish. As soon as I disconnect the serial console it returns to normal.

[CRCinAU]

I don't see this on mine - but I have it powered normally - ie not via USB...

[rstalde]

Hi guys,
I tested Marlin in version 09.08.21 without NEO-Pixel with board definition "STM32F103RC_btt_maple" (The board has only RC processor).
NEO pixels ended up with the error message .pio\libdeps\STM32F103RC_btt_maple\Adafruit NeoPixel/Adafruit_NeoPixel.h:361:3: error: 'GPIO_TypeDef' does not name a type so disabled those things

Result:
The original error was not reproducible even after 10 tries. (I have enough filament clips for now :D)
At the end of the print, the hotend moved to the predefined position and the heating elements were switched off, but the expired print remained active on the display (BTT touchmode), so I don't get any print data displayed.

I hope I could help with the troubleshooting ...

Addendum: I normally don't use a computer at the USB interface of the mainboard, so that I wouldn't notice the indicated performance drops.

[thinkyhead]

The cause for sluggish screen drawing / encoder response is still unknown. It's not specifically related to a serial console connection, nor directly related to playing beeps, so I'll have to do more testing to see where the firmware is spending most of its time.

[rstalde]

If you need more tests from my side, ask me ...
Normally I can do such things on the next day or the over next day ;)

[rstalde]

Hello All,
I have test-disabled the additional EEPROM and used (hopefully) the flashrom of the CPU instead.
For this I have, as the only change, modified the file ...\Marlin\src\pins\stm32f1\pins_BTT_SKR_MINI_E3_V2_0.h.

The following lines have been commented out:

// Onboard I2C EEPROM //RST commented out for test.
//#if NO_EEPROM_SELECTED
 // #define I2C_EEPROM
 // #define MARLIN_EEPROM_SIZE 0x1000 // 4KB
 // #undef NO_EEPROM_SELECTED
//#endif

Test:
15* the GCode M500 ... G4 S1

Result:
No error ;)

I then took a look at the datasheet of the used EEPROM:

• Bidirectional Data Transfer Protocol
• 100 kHz (1.8V, 2.5V, 2.7V) and 400 kHz (5V) Clock Rate

The IC is operated with 3.3V, so for 100kHz.
Could it be that it is "overclocked" by the software? (I am a technician, not a programmer ;))

I hope I could help with this information.

[rstalde]

Hi guys
after a week after my last post an intermediate status:
The described error while saving the data has not occurred anymore.
Therefore, it can be assumed that there were only problems with writing the / my EEPROM chip.

Has anyone been able to determine with which frequency is written to the chip?
Due to the supply voltage there are restrictions, as I had written in my last article.

[CRCinAU]

I did go hunting, but came up empty handed... The i2c code for the BL24CXX eeprom is here:
https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/libs/BL24CXX.cpp

Whilst it has all the init functions, there doesn't seem to be any mention of an i2c speed.

I think I'm getting my mainboards confused... I actually think the BL24CXX is for the Creality v4.2.x boards, not the BTT boards sigh...

[thinkyhead]

The described error while saving the data has not occurred anymore.

@rstalde —

With those lines in the pins file commented out, does the firmware end up picking and using a different type of EEPROM, such as one with an SPI interface or flash-based EEPROM emulation? From the comment above, the pins file wants to use I2C_EEPROM when no other EEPROM type is enabled.

The firmware generally shouldn't just crash but possibly something is running a long loop and failing to reset the watchdog, or maybe i2c is getting hung up, as i2c is an interrupt-driven interface. Or maybe there is a conflict, which could be revealed using PINS_DEBUGGING / M43.

I'll quickly compile your configs with those lines commented-out in the pins file, and see what EEPROM code ends up getting included, if any.

Maybe the OP @Doormat1 would like to help do some troubleshooting also.

[thinkyhead]

I see… With those lines commented we get this instead:

#if EITHER(NO_EEPROM_SELECTED, FLASH_EEPROM_EMULATION)
  #define FLASH_EEPROM_EMULATION
  #define EEPROM_PAGE_SIZE     (0x800U)           // 2KB
  #define EEPROM_START_ADDRESS (0x8000000UL + (STM32_FLASH_SIZE) * 1024UL - (EEPROM_PAGE_SIZE) * 2UL)
  #define MARLIN_EEPROM_SIZE    EEPROM_PAGE_SIZE  // 2KB
#endif

[thinkyhead]

As a troubleshooting test, try setting the MARLIN_EEPROM_SIZE in the pins file to 0x0800 (2KB). This will cause the i2c code to use a different method for calculating the i2c address, and maybe that will be more compatible with the chip on the board.

@thisiskeithb — Are we sure that BTT SKR Mini E3 V2 (#18088) always comes with a 4K EEPROM with i2c interface?

[thisiskeithb]

Are we sure that BTT SKR Mini E3 V2 (#18088) always comes with a 4K EEPROM with i2c interface?

As far as I know, but @bigtreetech will need to confirm.

The two SKR Mini E3 V2 boards I have here (genuine STM32 RE and RC variants) work with the default EEPROM settings from the pins file.

[rstalde]

@thinkyhead,
I will later, when the printer has finished its printout ;), do a test with the changed EEPROM size and see which EEPROM type was installed on my board.
I will have the result probably today in the early evening (TZ=CEST).

[rstalde]

@thinkyhead,
I have added the block you suggested in ...\Marlin\src\pins\stm32f1\pins_BTT_SKR_MINI_E3_V2_0.h.

For testing, I used the following gcode:
M75

M500
G4 P1000
M31
.
23 repetitions
.
M500
G4 P1000
M31

Result: 2 test runs, No error! :) :) :)

Second Test:
25 times M500 in Gcode-file: No error 👍

The built-in EEPROM is an AT24C32 (position U12 between TFT- and Neopixel connector)

So this looks like a possible solution for now.
I will now test this for a week in normal operation 🦺 (If no one else does it ;)) and then give feedback again.

[rstalde]

Hi guys
I have tested the proposed change for accessing the EEPROM for a few days now.
No more errors have occurred ;)
I think this is the solution to the problem.
THANK YOU from Germany for this excellent support!

[thisiskeithb]

Thinkyhead: Would forcing a 2K EEPROM size for everyone be OK?

@bigtreetech: Are there different EEPROM chips/sizes on the SKR Mini E3 V2 boards?

[rstalde]

On my board is a 32 K-Bit (4 K-Byte) EEPROM ...
But on what cases are needed more than 2 K-Byte???
I think 2 KB maybe OK in most cases.

[CRCinAU]

Just wanted to chase this up and see what the current consensus is?

The difficult part is, I haven't reproduced it in my system since - so it may well be an intermittent issue.

[ChrisToxz]

Just wanted to chase this up and see what the current consensus is?

The difficult part is, I haven't reproduced it in my system since - so it may well be an intermittent issue.

Don't think it is incidental, I have the same issue but didn't have time yet to flash a new instance with the adjusted EEPROM size.
will follow up asap.

I started to notice it a week ago when I finally upgraded Marlin to 2.0.9 cannot remember this issue with 2.0.7

Edit:
Okay did some tests.

Changing EEPROM size to 2KB -> Nothing changed, still crashing while saving EEPROM mid print. (Even got M112 printed halted errors)

I enabled the EEPROM debug config and got some inconsistent errors back.
First try:

Recv: echo:Error writing to EEPROM!
Recv: Error:Field tmc_stepper_current mismatch.

Second try:

Recv: echo:Error writing to EEPROM!
Recv: echo:Error writing to EEPROM!
Recv: echo:Error writing to EEPROM!
Recv: Error:Field home_offset mismatch.

Third try:

Recv: echo:Error writing to EEPROM!
Recv: echo:Error writing to EEPROM!
Recv: echo:Error writing to EEPROM!
Recv: Error:Field home_offset mismatch.

Fourth try:

Recv: echo:Error writing to EEPROM!
Recv: Error:Field esteppers mismatch.

With all tries I only changed the heating temperature of the preheat constants, so none of the mentioned fields where changed.

Do you want me to open a new issue? However specs, the expected, actual behavior & reproduce steps are the same.
When not in printing stage everything works fine.

[rstalde]

Hi @ChrisToxz,
did you once try to do without the EEPROM chip completely, like I did in #22524 (comment)?

I am not the programming expert, but I know relatively well with hardware ;).
Not that in the end it turns out that the EEPROM is operated in the limit range and therefore the error does not always occur and with all users.

[bigtreetech]

Hello, Can you try to force I2C to software I2C? In case of possible bugs in the hardware I2C library? Please tell me if the results have changed

[thisiskeithb]

Hello, Can you try to force I2C to software I2C? In case of possible bugs in the hardware I2C library? Please tell me if the results have changed

It would also be helpful to know:

1. Which processor your SKR Mini E3 V2 has (STM32 RCT6 or RET6)
2. Which environment you compiled with

[rstalde]

Hello people,
I have tried the suggestion of @bigtreetech:
Only inserting the line " #define SOFT_I2C_EEPROM " is not enough, because the pins for the EEPROM (SCL & SDA) are not defined.
So additionally the following is inserted:

// Define pins for EEPROM
#ifndef I2C_SDA_PIN
#define I2C_SDA_PIN SDA // SDA-pin from CPU to EEPROM
#endif

#ifndef I2C_SCL_PIN
#define I2C_SCL_PIN SCL // SCL-pin from CPU to EEPROM
#endif

Compiled with Visual Studio Code V. 1.60.0 with "Auto Build Marlin".

The first test (25 times M500 , G4 P1000 , M31) ran without errors.
I will test this now for some days ...

If this was the reason for the error, then BTT may sponsor me the next upgrade for the trouble ... (nonsense, joke ;))

PS:
... Forget it ... what was written at this point did not really work.

[rstalde]

Hello people,
I have tested the alternative access to the EEPROM for a few days now. No more errors have occurred.
This method was apparently already used in Marlin 2.0.8 (source code on BTT's website).

The implementation in the PINS file currently looks like this:

// Onboard I2C EEPROM
#if NO_EEPROM_SELECTED
#define I2C_EEPROM
#define SOFT_I2C_EEPROM //RST
#define I2C_SDA_PIN SDA //RST
#define I2C_SCL_PIN SCL //RST
#define MARLIN_EEPROM_SIZE 0x1000 // 4KB
#undef NO_EEPROM_SELECTED
#endif

I think this solves the originally reported problem.
Thanks to those who supported me with this!

[leweljun]

This also worked for me.

Hello people,
I have tested the alternative access to the EEPROM for a few days now. No more errors have occurred.
This method was apparently already used in Marlin 2.0.8 (source code on BTT's website).

The implementation in the PINS file currently looks like this:

// Onboard I2C EEPROM
#if NO_EEPROM_SELECTED
#define I2C_EEPROM
#define SOFT_I2C_EEPROM //RST
#define I2C_SDA_PIN SDA //RST
#define I2C_SCL_PIN SCL //RST
#define MARLIN_EEPROM_SIZE 0x1000 // 4KB
#undef NO_EEPROM_SELECTED
#endif

I think this solves the originally reported problem.
Thanks to those who supported me with this!

[rstalde]

Today I tested the brand new version 2.0.9.2 in the configuration described above (BTT-SKR Mini E3 V2.0 in Ender 5).
Unfortunately, the error from the original error message occurred sporadically.
With the change of the PINS file, which I described on September 20, the error did not occur even after 50 M500 commands.
(Configuration files: Ender 5, SKR Mini E3 V2, BL-Touch, 14 * Neopixel, Titan-Extruder DD, Display: BTT TFT35-E3 V3.0)

BTT-E5-V2092.zip

[GeorgeDLake]

Same problem BTT-SKR Mini E3 V2.0 on an Ender 3 Pro.

[rstalde]

@GeorgeDLake, you can use the file "..\Marlin\src\pins\stm32f1\pins_BTT_SKR_MINI_E3_V2_0.h" from the archive "BTT-E5-V2092.zip" (See my post from October 3 and previous).
This solution to the problem has worked absolutely flawlessly for me for several weeks now :)

Please leave a comment here (and also other people) if this solved the problem, as the error may be very sporadic and cannot be reproduced reliably.

[domtisdell]

This looks to have solved it for me. I've 2 x Ender 3 Pro running SKR Mini E3 V2.0 and TH3D's Unified v2.34a firmware based on Marlin 2.0.9.1 and was having this problem constantly, specifically when saving Z offsets the 2nd time while priniting. No issues now on either printer after a handful of prints.

[thisiskeithb]

See #22919.

[thisiskeithb]

#22919 was merged. Closing.

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