- This topic is empty.
-
AuthorPosts
-
-
February 15, 2016 at 12:30 pm #113259tmoravanParticipant
Hello –
I recently powered up one of my H8000FW’s and it came up with an error message after booting. Basically it said there was a problem and to check the Info section under Setup. When I went there, the message was: Problem in internal RAM Bad Checksum.
In the old days, carefully removing the RAM ICs and reseating them would typically fix this type of problem. Since the H8000 is mostly soldered to the board surfacemount, this doesn’t work.
So my question is – can I run any other diagnostics to narrow down the problem and is there an option other than sending the main board (or whole unit if I must) back to Eventide?
thanks for any assistance.
-
February 15, 2016 at 3:40 pm #142566
First thing to try is "Fixing PCMCIA SRAM Memory Card Problems" on p.148 of the UM.
If the problem re-appears, it would indicate that the battery needs changing. This requires some disassembly and should be performed by a technician with the power disconnected.
It is possible that it is a hardware fault, but unlikely.
-
February 15, 2016 at 5:14 pm #142569tmoravanParticipant
Thanks. I was guilty of posting before looking at the manual.
I did an internal format and it rebooted clean, then I installed the 5.6 update (machine was at 5.5) and that installed cleanly. The manual strongly suggests to do an internal format versus just clearing the error. Any comment/opinion on that?
-
February 16, 2016 at 4:02 pm #142576
Because the bad checksum implies some fault in the data, you might want to consider re-formatting the memory to get it to a known state. The checksum error may not mean anything (it could be a fault in unused data), but there is value in being sure.
But, be aware that this is in effect a re-initialization, so save any important user stuff first to a card.
-
April 14, 2019 at 6:40 pm #151701sean.eParticipant
Resurrecting this thread…
I’m curious if I could determine what data changed. When is the saved checksum written? Any time there is a write to RAM?
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? 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).
I think in summary, the questions are:
– 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?
– 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?
-
April 15, 2019 at 3:00 pm #151708
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).
-
April 15, 2019 at 5:42 pm #151712sean.eParticipantnickrose wrote:
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).
Thanks Nick. After I replace the battery, I’ll try some experiments just as an exercise in curiosity. For example, I’ll change the setup, save, and restart to see if the checksum error goes away. If not, repeat for routings. If not, finally repeat for presets. At the end, if the error still occurs, then I’ll do a reinit.
-
-
April 18, 2019 at 2:22 pm #151757
Hi Sean – having given it some thought, I'm not sure your approach will work, as anything you save will just update the faulty checksum, so it will remain faulty (255 times out of 256 – it's only a byte value).
I think you'll end up having to do the "fix checksum" or a full reinit.
-
-
AuthorPosts
- You must be logged in to reply to this topic.