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
Yes, I think you will have to add another end symbol. Either that, or you'll have to change your off-board CRC calculator to 1) assume all bytes not overwritten by the .hex file to be 0xff (i.e.: implement the apparently buggy /p option of hex2bin in the CRC calculator instead) 2) let it jump over the 0xe000...0xffff part automatically. No matter how you do it, the goal is that the data actually presented to the CRC calculation must be exactly the same on both ends of the equation. One alternative is to let the micro calculate and write the CRC itself, after the program has been downloaded to it, instead of trying to replicate what it would do using only off-line tools.
I did the following test: Created a file ORIGINAL.HEX containing
:00000001FF
HEX2BIN /L0x10 /P0x11 ORIGINAL.HEX TEST.BIN
BIN2HEX TEST.BIN NEW.HEX
:1000000011111111111111111111111111111111E0 :00000001FF
I seem to recall that HEX2BIN requires a length argument for the pad byte to work. Arguments specified to HEX2BIN may be entered in either HEX (/p0x11) or in decimal (/p17). Jon
Thanks for all of your tips so far! Especially the "another symbol"-hint by Hans and the "/L"-hint by Mike and Jon seem to be the solution for my problem. I'll give that a try tomorrow at work ... Thanks and good night! Torsten