Make EEPROM storage consistent

[thinkyhead]

Update ConfigurationStore to always write dummy values for disabled options, including FWRETRACT, DELTA, and SCARA. Update the EEPROM version to “V15.” Also fixed a buffer overrun with axis_scaling in Config_ResetDefault.

[clefranc]

Problem with PIDTEMP aligment again: if 16 values are written, 16 must be read.

297 + // 4 x 4 = 16 slots for PID parameters
298 + for (int q=16; q--;) EEPROM_READ_VAR(i, dummy);

[clefranc]

Also, should not it be a section for volumetric extrusion?

59 + * VOLUMETRIC EXTRUSION
60 + * volumetric_enabled
61 + * filament_size (x4)

[CONSULitAS]

@thinkyhead
Hi Scott,
great work! This should help a lot.
What do you think, wouldn't it be a good idea to implement a write verify here?
We could read the written *value and check if it worked. If not, give it some 2 or 3 retries.
If the retries don't work, give a error message to serial.
Something like

void _EEPROM_writeData(int &pos, uint8_t* value, uint8_t size) {
  uint8_t retries,
              value_read;
  int pos_read;

  do {

    retries = 0;
    do {
      eeprom_write_byte((unsigned char*)pos, *value);
      value_read = eeprom_read_byte((unsigned char*)pos);
    } while ( (*value != value_read) && (retries++<3) )

    if (*value != value_read) {
      SERIAL_ECHO_START;
      SERIAL_ECHOPAIR("ERROR writing to EEPORM: at pos ", pos);
      SERIAL_ECHOPAIR(" wrote " , *value);
      SERIAL_ECHOPAIR(" read " , value_read);
      SERIAL_ECHOLN("");
    }

    pos++;
    value++;
  } while (--size);
}

This is just a q+d hack, but could help.

This would perhaps fix #416 in nearly most cases. @daid told 20 days ago :

We had to replace a few Arduino's at Ultimaker due to the EEPROM not working properly (settings got lost all the time)

In all other cases there would be a feedback to the user.

Cheers

[daid]

Note that's it's very rare for EEPROM not to work, according to what I've seen. We've shipped thousands of printers, and only a few showed this problem.

[CONSULitAS]

@daid I see. And #416 seems to be a hard to repoduce problem, too.

But wouldn't it be safer to check nevertheless? What if EEPROM gets old and fails after some years? Even Harddisks and SSDs do verify and the are good for many TB written.

I think this would use only some bytes of RAM and PROGMEM, and performance is IMHO not critical during writing to EEPROM. And I am not sure if every supplier checks his boards for shipping.

Cheers

[clefranc]

@CONSULitAS
I like the idea of a write check, and if you go this route, can I suggest to make a read check too?

If the same data is to be written to the same position, then skip this write.

Another suggestion is to add a bad EEPROM cell map, where you can add positions reported by the failed write check, and skip these positions. This is surely overkill for the amount of data and write cycle we use here, but it could make someone happy to regain access to his EEPROM.

[thinkyhead]

@clefranc I will fix the PIDTEMP alignment asap.

@CONSULitAS I like the idea of verifying write to catch hardware errors. If it fails even once, that should be flagged.

[thinkyhead]

@clefranc OK, I fixed the PIDTEMP restore proper alignment.

The volumetric options seem to be fine as they are. There's no #define to enable/disable the volumetric_enabled variable, so I have not labeled that section or enclosed it in an #if block. If the volumetric code becomes conditional, then I'll add a label and enclose those parts in a block.

[clefranc]

@thinkyhead
So? What's wrong?

[thinkyhead]

@clefranc Last commit failed the build due to a bad line. Fixed.