- Eventide Audio

Home Forums Products Rackmount H8000FW internal RAM checksum error Reply To: H8000FW internal RAM checksum error

Eventide Staff

The user data and presets are stored in battery backed memory. A checksum (the arithmetic sum of all the bytes) is maintained, and is updated every time the memory is written. The checksum is recalculated from time to time and compared against the stored checksum.

This means that should the memory be corrupted, the above comparison will fail, and the user can be alerted of a possible problem,.

>> If the corruption was in a preset due to a dying battery, after I replace the battery, if I were to send all my presets to the device and rewritten, at the next start would the checksum error go away or does the error message have to be cleared? 

The checksum error normally has to be manually cleared. See "Fixing Internal Memory Problems" in the UM, leading to SETUP/service/fix internal

>> Basically, I sort of would like to know if the corruption is in a preset, routing or setup.  And does rewriting a preset mean that if the corruption was in the routing data, recompute of the checksum would now occur with corrupted routing data (meaning no error reported, without knowing if the corruption was actually addressed because I updated an uncorrupted preset rather than corrupted routing data).

Sorry – there is only one checksum, that covers all user data.

>> Does the checksum error message have to be cleared, or if the corrupted data was successfully replaced with uncorrupted data, would the error be gone at next startup?

It normally has to be manually cleared, but in the unlikely event that you managed to replace the corrupted data with the correct data, it would magically fix itself.

>> Does the act of writing to any memory cause the checksum to be updated, meaning that data corruption in data unrelated to the write would now be 'baked' into the new checksum?

It does. The stored checksum is updated with every write to memory. But, it doesn't recalculate the entire checksum (too slow), it just updates if for the new data. This means that if it was bad before a write, it will still be bad (255 times in 256).