Данный пост продолжает тему и отвечает на вопрос поднятый в треде Gold card ???
Код:
Итак, рассмотрим начало содержимого EEPROM, которое генерирует
преусловутоя программа TwinSim.
:10 0000 00 31313131FFFFFFFF39383738FFFFFFFF 00
:10 0010 00 33333333333333333333333333333333 F0
:10 0020 00 3FF2FF4F24F234F1CC23C23CF1324FCD E0
:10 0030 00 0977777777777777777709F1CC23C23C D0
:10 0040 00 F1324FCD096D3CFF7C54ADD00001040A C0
:10 0050 00 010302097DD6D0A2F14FEC000004FFFF B0
:10 0060 00 FFFF010A0300000004CF3FCF0F03FFFF A0
:10 0070 00 FF05FFFFFF00000213FF140032008CFF 90
:10 0080 00 FFFFFF0034FFFFFFFFFFFFFFFFFFFF10 80
................................................
Напомню фрагмент описания формата HEX (конечно, исключительно для тех, кто подзабыл - уверен, что пригодится еще не раз...)
General Record Format
| RECORD | LOAD | | | INFO | |
| MARK | RECLEN | OFFSET | RECTYP | or | CHKSUM |
| ':' | | | | DATA | |
1-byte 1-byte 2-bytes 1-byte n-bytes 1-byte
Each record begins with a RECORD MARK field containing 03AH, the ASCII code for the colon (':') character.
Each record has a RECLEN field which specifies the number of bytes of information or data which follows the RECTYP field of the record. Note that one data byte is represented by two ASCII characters. The maximum value of the RECLEN field is hexadecimal 'FF' or 255.
Each record has a LOAD OFFSET field which specifies the 16-bit starting load offset of the data bytes, therefore this field is only used for Data Records. In other records where this field is not used, it should be coded as four ASCII zero characters ('0000' or 030303030H).
Each record has a RECTYP field which specifies the record type of this record. The RECTYP field is used to interpret the remaining information within the record. The encoding for all the current record types are:
'00' Data Record
'01' End of File Record
'02' Extended Segment Address Record
'03' Start Segment Address Record
'04' Extended Linear Address Record
'05' Start Linear Address Record
Each record has a variable length INFO/DATA field, it consists of zero or more bytes encoded as pairs of hexadecimal digits. The interpretation of this field depends on the RECTYP field.
Each record ends with a CHKSUM field that contains the ASCII hexadecimal representation of the two's complement of the 8-bit bytes that result from converting each pair of ASCII hexadecimal digits to one byte of binary, from and including the RECLEN field to and including the last byte of the INFO/DATA field.
Therefore, the sum of all the ASCII pairs in a record after converting to binary, from the RECLEN field to and including the CHKSUM field, is zero.
Как хорошо видно, автор TwinSim’a не позаботился о подсчете КС(CHKSUM), и, как следствие этого, НИ ОДИН программатор работающий с данными в HEX формате ЭТО зашивать и не ДОЛЖЕН!
Чтобы долго не возится, я обычно конвертирую такое фуфло в BIN с помощью любимого WinHex 11.9 ... и всё!
З.Ы. Кстати, обратите внимание на то, как в одну кучу свалены PIN1, PIN2, KI1, KI2, IMSI1, IMSI2,... Никакой структуры нет и в помине – ВОТ ОНО иногда 
И НЕ РАБОТАЕТ!
Ответить с цитированием
