Tried to flash the newest Allted/Marlin firmware for my MPCNC after setting up the dual end stops and I’ve repeatedly gotten “EEPROM data size error”. I tried M502, 500 as suggested in the GitHub issues page for Marlin: https://github.com/MarlinFirmware/Marlin/issues/11699
If I configure OctoPrint to ignore the error, everything seems to work fine. However, I’ve downgraded to the previous firmware (412D) which has no errors.
I also tried reinstalling the newest firmware but the issue persists.
Changing monitoring state from “Offline” to “Detecting serial port” Serial port list: [’/dev/ttyACM0’] Connecting to: /dev/ttyACM0 Changing monitoring state from “Detecting serial port” to “Opening serial port” Connected to: Serial<id=0xffff804a92d0, open=True>(port=’/dev/ttyACM0’, baudrate=250000, bytesize=8, parity=‘N’, stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Changing monitoring state from “Opening serial port” to “Connecting” Send: N0 M110 N0125 Send: N0 M110 N0125 Recv: start Send: N0 M110 N0125 Recv: echo:Marlin 418D bugfix-2.0.x Recv: Recv: echo: Last Updated: 2020-01-22 | Author: (V1 Engineering, Ryan, 418D) Recv: echo:Compiled: Feb 18 2020 Recv: echo: Free Memory: 3395 PlannerBufferBytes: 1488 Recv: echo:SD card ok Recv: Error:EEPROM datasize error. Recv: echo:Index: 623 Size: 619 Recv: echo:Hardcoded Default Settings Loaded Recv: Error:EEPROM datasize error. Recv: echo:Index: 623 Size: 619 Recv: echo:Hardcoded Default Settings Loaded Recv: echo:SD card ok Recv: Error:EEPROM datasize error. Recv: echo:Index: 623 Size: 619 Recv: echo:Hardcoded Default Settings Loaded Recv: Error:EEPROM datasize error. Recv: echo:Index: 623 Size: 619 Recv: echo:Hardcoded Default Settings Loaded Recv: ok Changing monitoring state from “Connecting” to “Operational” Send: N0 M110 N0125 Recv: echo:Unknown command: “” Recv: ok Send: N1 M115*39 Recv: FIRMWARE_NAME:Marlin 418D bugfix-2.0.x (GitHub) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:V1 CNC EXTRUDER_COUNT:0 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff Recv: Cap:SERIAL_XON_XOFF:0 Recv: Cap:BINARY_FILE_TRANSFER:0 Recv: Cap:EEPROM:1 Recv: Cap:VOLUMETRIC:0 Recv: Cap:AUTOREPORT_TEMP:0 Recv: Cap:PROGRESS:0 Recv: Cap:PRINT_JOB:1 Recv: Cap:AUTOLEVEL:0 Recv: Cap:Z_PROBE:0 Recv: Cap:LEVELING_DATA:0 Recv: Cap:BUILD_PERCENT:0 Recv: Cap:SOFTWARE_POWER:0 Recv: Cap:TOGGLE_LIGHTS:0 Recv: Cap:CASE_LIGHT_BRIGHTNESS:0 Recv: Cap:EMERGENCY_PARSER:0 Recv: Cap:PROMPT_SUPPORT:0 Recv: Cap:AUTOREPORT_SD_STATUS:0 Recv: Cap:THERMAL_PROTECTION:1 Recv: Cap:MOTION_MODES:1 Recv: Cap:CHAMBER_TEMPERATURE:0 Recv: ok
In the history it looks like this is in there but maybe mangled since then. The maintainers don’t ever use EXTRUDERS == 0 so it’s easy to get broken. I’ll take a look and see if I can pin it down specifically.
Okay it looks like this got fumbled during the merge. I’m a little surprised it hasn’t been seen sooner.
According to this PR there was a subsequent commit f2b54c1 (not the first commit) that added the #IF EXTRUDERS stuff, but when it got merged, it got pulled back out (probably from a stale file diff or something).
Again I’m puzzled why this wouldn’t have been seen before. You can try manually patch the code using the differences shown here: f2b54c1. But I can’t be sure this is enough. I’ll take a look later and submit a PR against upstream Marlin if I can prove that’s the error.
OK, so I got it working after I manually changed the lines according to your PR (I didn’t bother using git, which probably would have been easier in retrospect).
After uploading the firmware, I did get a CRC error. This time running M502 then M500 did the trick. No errors now.
Thanks again for your incredible speed!
PS. I noticed that there is a section in the forum for Software/Firmware… guess I should have posted there.
Grrrrrr, I even saw this error…many times and brushed it off to actually enabling eeprom again. Dangit.
All good, when this gets pulled I will update them all again. It has to be tested again though as they messed with the dual stuff right after 418 so I have been hesitant to update, testing takes a long time. Speaking of. I think I am going to stop testing ramps, if all the rest work I will assume ramps is okay.
If you wanted a near-term fix you could apply a small patch to 418 and 418D to make 419 and 419D, and that should relieve any time pressure. Eventually when/if the PR makes its way into bugfix-2.0.x you can merge and no hurry on testing to release the next one.
I wouldn’t worry about ramps. It should work fine, and in the unlikely event that it breaks, somewhere between bugfix-2.0.x and the Rambo version the answer won’t be far off.
So what it’s doing is clearing it out and resetting to default each boot?
Any reason why it would repeat the message 4 times? Is it just really persistent?
I’m making the connection using cncjs from the v1pi image.
418D is an old version that has a bug with the EEPROM size error that will never clear and effectively prevents you from saving any settings with M500.
Upgrade to a newer version unless you can do without M500. (If you don’t need to save any settings then you can ignore the error.)