My machine is running Marlin 1.1.4. Prior to today it had a Chimera extruder and today I installed a Cyclops and recompiled and uploaded firmware. Now I receive:
Recv: start
Recv: echo:Marlin 1.1.4
Send: N0 M110 N0*125
Recv:
Recv: echo: Last Updated: 2017-07-04 12:00 | Author: (none, default config)
Recv: Compiled: May 25 2018
Recv: echo: Free Memory: 3790 PlannerBufferBytes: 1232
Recv: Error:EEPROM CRC mismatch - (stored) 47364 != 219 (calculated)!
Changing monitoring state from "Connecting" to "Error: EEPROM CRC mismatch - (stored) 47364 != 219 (calculated)!"
Changing monitoring state from "Error: EEPROM CRC mismatch - (stored) 47364 != 219 (calculated)!" to "Offline (Error: EEPROM CRC mismatch - (stored) 47364 != 219 (calculated)!)"
Connection closed, closing down monitor
Octoprint forces a disconnect. I'm not sure how to proceed. Help?
This solution didn't seem to point to the correct Octoprint page and I couldn't find the option checkbox that is labeled "Ignore and unhandled errors from the firmware...": http://forums.reprap.org/read.php?415,814275
For me, solution in your link sounds not bad. You should give it a try.
Unfortunately you didn't say which OctoPrint version you use.
Nevertheless in 1.3.8 you'll find the said option in Settings -> Serial Connection -> Behavior -> Error Handling -> What to do on firmware error
1 Like
Wouldn't you want to re-upload the image in a case like this?
The CRC is used to verify that the last upload or the last write/update completed. When that's incorrect then the assumption is that the image is trashed.
1 Like
Thank you for the instructions to get to the equivalent menu option. The solution in the link worked perfectly.
Just to summarize, this EEPROM CRC mismatch error (feature?) is caused when you upload a different version (or changed settings) of Marlin firmware.
If you have an LCD on your printer, navigate to Configuration, Store Settings (or Restore Failsafe) and press the button, this will write a new CRC checksum and fix the error.
You will, of course, have to configure the EEPROM settings to appropriate values for this new firmware.
On my LulzBot TAZ 6, I get this error every time I change tool heads (single to dual, etc.).
For real? To me, this indicates that whatever is trying to write to the EEPROM isn't doing its job right.
You might be right but it is a "feature" Marlin added to detect corruption of the EEPROM.
Problem is that because configuring Marlin is primarily done at compile time, the contents of the EEPROM changes and Marlin has no way of knowing what the "old" contents were. I don't think Marlin has a "first use" mechanism which is where I would expect a fix to be implemented.
The firmware bootloader would be another place for a fix to be implemented but the bootloader being used precedes the Marlin "feature" by quite a bit.
Interesting... and sad.
For what it's worth, I've been using the EEPROM Marlin Editor plugin for about a year now and I've never seen anything throw a CRC error. I have two different beds so I'm always adjusting the Z-home back and forth as required.
Yours @b-morgan almost sounds a bit like this issue, for what it's worth. And yes, I saw this.
@OutsourcedGuru thanks for those pointers. I think this is still an issue when the old and new firmware have a different "#define EXTRUDERS" which is exactly my case as I'm changing back and forth between a single extruder tool head and a dual extruder tool head.
I'm mostly just trying to understand this since I haven't yet compiled Marlin (but I'm a long-time C/C++/C# programmer).
I assume that just making a pragma change like that then adds in some additional code or otherwise changes some logic. It eventually compiles to an executable, presumably a .BIN or .HEX file and then...
magic happens
...and it's now existing as firmware on something persistent on the RAMPS board. I'm guessing this is the same EEPROM which also remembers Z-Home, etc.
I would guess that the magic step is the act of overcopying (flashing) the EEPROM rather than a function in the RAMPS memory which reaches out and patches itself from the external file. If it's the former, in my mind the acting of flashing the EEPROM includes the activity/responsibility to update the CRC or maybe that's the responsibility of a routine that's embedded somewhere else.
If I'm correct in assuming that a lot of RAMPS boards run on Arduino, I'd think that this could be useful at least to me to understand it. That routine calculates it. Given this message:
Recv: Error:EEPROM CRC mismatch - (stored) 47364 != 219 (calculated)!
...and what was stated, it seems clear to me that whatever flashed the EEPROM didn't also update the "stored CRC", wherever that is.
Given that OctoPrint indicates that this entire message came from Marlin, I have to assume that the stored CRC is in Marlin itself. From what I think you're suggesting, this is completely a Marlin problem.
But if OctoPrint allows a firmware update, could the routine in OctoPrint be:
- flash the EEPROM
- do something that will re-calculate the CRC and store it
This is, indeed, a Marlin issue. I believe it is caused by a change in the amount of data stored in the EEPROM (the PID values for each extruder) when the number of extruders changes (there may be other cases as well). After flashing, the new firmware doesn't know how many extruders the old firmware had configured. I don't believe the bootloader does anything with the EEPROM (i.e. it isn't loaded with the firmware).
Some slicers which also serve as the firmware updater can execute an M500 or an M502 at the end of flashing which will clear the error.
The OctoPrint Firmware Updater cannot issue commands until OctoPrint connects to the printer, and OctoPrint gets the error as soon as it connects which, by default, causes the connect to fail.
The workaround is the set the OctoPrint Serial Connection Behavior from disconnect on error to cancel print but stay connected. In the Firmware Updater options, set the Post-flash Settings to Enable post-flash gcode and issue an M500 or an M502.
The only clean solution is for Marlin to somehow recognize that this EEPROM CRC error is the result of a firmware update and suppress sending it to the host. OctoPrint is designed to be firmware agnostic so I don't see this as a problem OctoPrint should tackle, and the plugin environment is limited to what the API provides. Furthermore, the plugin is designed to support as many printers and firmwares as possible so a special case for this scenario is probably not appropriate.
Since the workaround works quite well, I'm happy with that solution. Now the only thing left is to help others who run into the problem by publicizing the workaround as the solution.
2 Likes
And since you've reached out to them, you'd think that they would eventually do the right thing. Gotcha. (Thanks.)
Just to chime in here. I have an Ender 5 Plus (two actually with this described problem) that has a notoriously poor firmware in regards to either being able to use either OctoPrint or the touch screen display. In other words I can connect the Raspberry Pi and the Pi will connect accordingly but I will loose responsiveness to the display. In some rare cases I can turn the machine on and if the gods deem whatever Tuesday afternoon in my favor I can use both the screen and OctoPrint.
All that to say is I experience the issue found in this thread after doing a bed level on the touch screen and after making adjustments I neglected to hit the "Z Home" button that I thought meant 'go to Z home' rather than 'make this Z Home' so I suppose that since there had been unsaved changes in Marlin I couldn't connect my Pi until going back to level and apply the changes by clicking the button NOT labeled "Apply Changes" or something similar.
Thank you for the tips here!