This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ROM-Check Part 2

Hello again :)

I want to do a ROM-CRC-Check (C167CR-LM, 1 MB ext.Flash-ROM).
The following steps are already done: (see Thread "Locating the end of the used FlashROM" for more details)
1. Keil's OH166 creates an Intel-Hex-File
2. Keil's HEX2BIN converts it to a BIN-File
3. My own CRC-Proggie appends a CRC-Sum to this BIN-File
4. Keil's BIN2HEX converts it this BIN-File back to Intel-Hex-Format
5. Flash-Download
6. The Application gets the appended CRC-Sum out of the Flash-Memory
7. The Application calculates the CRC-Sum over the USED Flash-Memory

The Memory-Map looks something like this:
00:0000 - 00:7xxx Program-Code
00:7xxx - 00:DFFF unused
00:E000 - 00:FFFF reserved for internal RAM / CAN-Registers / SFR etc.
01:0000 - 01:1xxx Constants / last Part of the Program Code / CRC
10:0000 - 13:FFFF 256K RAM

Now my Problem:
The appended CRC-Sum is located at the and of the USED ROM-Area anywhere around 01:1xxx and was calculated over the BIN-File (Size approx. 66kB). In that BIN-File unused Bytes do have the Value 0x00 (so the whole Area 00:8000 .. 00:FFFF consists of 0x00's). At the target Dialog of Keil's uVision2 the Flash-Fillbyte is set to 0xFF, but this value is only used to fill up the last line to 16 Bytes.
But in the Flash-ROM the unused Bytes have the value 0xFF and so I cannot calculate the same CRC-Checksum as over the BIN-File :(
Is there any possibility
a) to set unused/reserved Bytes in the HEX-File and so in the BIN-File to 0xFF or
b) to get the area of unused space between 00:7xxx and 00:FFFF ?

Thanks
Torsten

Parents
  • I did the following test:
    Created a file ORIGINAL.HEX containing

    :00000001FF
    only end of file record.
    Created a 16 byte long binary padded with the 0x11 byte
    HEX2BIN /L0x10 /P0x11 ORIGINAL.HEX TEST.BIN
    Converted it back to hex
    BIN2HEX TEST.BIN NEW.HEX
    Here is what I got:
    :1000000011111111111111111111111111111111E0
    :00000001FF
    To me it looks like the /P option is working. But it still doesn't prove that there are no bugs in the HEX2BIN utility.
    Maybe you should do a google search for an alternative HEX2BIN? I'm sure there are a few out there. Besides, it's not really THAT difficult to write your own HEX2BIN utility. Or, even better, write a proggie that would append CRC record directly to HEX file.

    - mike

Reply
  • I did the following test:
    Created a file ORIGINAL.HEX containing

    :00000001FF
    only end of file record.
    Created a 16 byte long binary padded with the 0x11 byte
    HEX2BIN /L0x10 /P0x11 ORIGINAL.HEX TEST.BIN
    Converted it back to hex
    BIN2HEX TEST.BIN NEW.HEX
    Here is what I got:
    :1000000011111111111111111111111111111111E0
    :00000001FF
    To me it looks like the /P option is working. But it still doesn't prove that there are no bugs in the HEX2BIN utility.
    Maybe you should do a google search for an alternative HEX2BIN? I'm sure there are a few out there. Besides, it's not really THAT difficult to write your own HEX2BIN utility. Or, even better, write a proggie that would append CRC record directly to HEX file.

    - mike

Children