| jd |
Posted - 12/20/2012 : 06:08:28
Using a GMC-300 with firmware version "GMC-300Re 2.30", here's some raw data extracted from the 64 KiB memory via the USB serial interface:
61F0: 55 AA 01 02 74 55 AA 01 02 2C 55 AA 01 02 79 55
6200: 01 02 1C FF 55 AA 01 02 35 55 AA 01 02 66 55 AA
6210: 01 02 56 55 AA 01 02 4E 55 AA 01 02 59 55 AA 01
6220: 02 38 55 AA 01 02 80 55 AA 01 02 4C 55 AA 01 02
6230: 70 55 AA 01 02 3C 55 AA 01 02 A1 55 AA 01 02 2B
With "55 AA 01" indicating a following 16-bit (two byte) value, this data would decode to the following readings in hexidecimal:
0x274, 0x22C, 0x279, 0x55,
0x1, 0x2, 0x1C, 0xFF, 0x235, 0x266,
0x256, 0x24E, 0x259,
0x238, 0x280, 0x24C,
0x270, 0x23C, 0x2A1, 0x22B
Notice the values that don't fit the trend.
Note too that the address 0x6200 occurs on a 0x100 byte boundary.
It seems as if an intended sequence of 55 AA 01 02 1C required two separate writes due to the boundary, but then was misaligned for the second write, losing the AA, and revealing an FF which would have been over-written by the 1C if the alignment had been correct.
At another memory location:
55 AA
5EF0: 01 02 21 55 AA 01 02 3C 55 AA 01 02 0C 55 AA 01
5F00: 1B FF 55 AA 01 02 7C 55 AA 01 02 4A 55 AA 01 02
5F10: 33
This decodes to readings of:
0x221, 0x23c, 0x20c,
0x1BFF, 0x27C, 0x24A,
0x233
Here again at a 0x100 byte boundary the same bad behavior appears, except this time data is lost and an erroneous reading of 0x1BFF (7167 in decimal) replaces the correct reading, unknown but probably 0x21B (539 in decimal). Due to the firmware bug, the device records a false value over 13 times higher than the likely correct value here.
This problematic behavior continues to repeat itself throughout the saved history data.
Does anyone know if there is currently a firmware version available that corrects this bug that causes potential data loss every 256 bytes?
|
