I have a G120E product that has been duplicated many times and distributed to customers. A very few units crash with a System Exception during initialization of the Nehaven LCD (model NHD-4.3-480272EF-ATXL-CTP) in the GHI.Processor.Display.Save() method. If I connect through FEZ Config I see the following error message just before the crash:
FAILED HEADER CRC at a090eb24: 0xe4a1d0d8 != 0x00000008
I do not see this message from the Visual Studio debugger, however. I have also noticed that the CRC address changes if I load a different version of my firmware, for example:
FAILED HEADER CRC at a09051d0: 0xe4a1d0d8 != 0x00000008
Can anyone at GHI provide insight into this message? Have any other G120E users noticed anything like this?
Thanks!
It seems like the config region is getting corrupt
1 Like
Thanks, @John_Brochue, I used GHI.Processor.Configuration.Read() to access the config space on a failing unit and a good unit. A simple compare confirmed that the configuration space was corrupted, and after re-loading the Config.hex file through FEZ Config the system returned to normal operation.
Now I am left to wonder how this corruption could have happened at the customer’s site, since my firmware does not use the Processor.Configuration class. Obviously TinyCLR must read this (since I got the error), but is it also rewritten? Could corruption occur if the customer powered-off the unit in the middle of a config-space update? But another weird thing is that two machines from the same customer exhibited this problem, and I have not seen it elsewhere. Any thoughts?
The config region is written, but usually in response a program request, like updating display, network, or usb config as you’d expect. If there’s a common and reproducible way to get the device to become corrupt it’s something we could look at.
