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
I thought the HEX2BIN utility had the option /P. Doesn't it do exactly what you want?
I suspect the 0x00:E000 -- 0x00:FFFF region is your problem. It's not ROM, so it could contain anything. I think you'll have to change your CRC computation to only run over ranges 0x00:0000 .. 0x00:dfff and 0x01:0000 .. END. While at it, maybe you can skip the unused area, too. The key to doing that is to use a linker directive to position a symbol at the exact end of all executable code, so you know where that is.
@Mike: Yes ... it doesn't ... :( If I use
HEX2BIN.EXE /P16 test.h86
:020000020000FC :10000000FA000401FFFFFFFFFFFFFFFFECFDF0C858 ... (Program Code) ... :106B1000F7F820A1DB00FFFFFFFFFFFFFFFFFFFFD4 :020000021000EC :1000000001403DA3000001403EA3000015403FA376 :1000100020202020202020202020202020202020E0 :00000001FF
00:0000 FA000401FFFFFFFFFFFFFFFFECFDF0C8 ... (Program Code) ... 00:6B10 F7F820A1DB00FFFFFFFFFFFFFFFFFFFF 00:6B20 00000000000000000000000000000000 00:6B30 00000000000000000000000000000000 ... (filled up with 0x00) ... 00:FFF0 00000000000000000000000000000000 01:0000 01403DA3000001403EA3000015403FA3 01:0010 20202020202020202020202020202020
... and how should the CRC-Append-Program "know", where the first used area ends and wherefrom the 0x00's are just fillbytes in the BIN-File?
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
Hi, I'm starting work on a ST10 project which has 1MB of external flash. I'd like to compute a checksum at complile,link time and download it into my target for comparison at runtime. I would be very interested in your checksum application for the PC. Regards Gary Morgan
I would be very interested in your checksum application for the PC. http://www.keil.com/support/docs/494.htm Jon