We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
After a considerable amount of effort, I have found a problem that can be traced back to the hex file generated by the Keil C compiler. The hex file seems to meet the Intel hex file specification, but it is incorrectly translated into a binary file by several translation programs. ( One EPROM emulator utility and an EPROM programmer software package.) The following is the first part of the hex file generated by the compiler version 1.32. :104C39002D48454D205361772D000A2A2A2A2045FF :104C490052524F52202A2A2A3A2025730A000A531F :0B4C590054415455533A2025730A00C3 :103EAC004102AF00410290004100100041000500AA :103EBC00410015004102E001410291004402E4007E :103ECC000000004402CC00000000440292000000FC :103EDC000044029E000000004402960000000044D2 :103EEC000011000000004402A40000000042000D7C :103EFC00000042000300004202A200004202AD009A :103F0C00004400180000000044012600000000429C :103F1C000006000042028E00004202A8000042028D :103F2C009C00004202B2000042000100004202E18B :103F3C0000004202AA00004202C400004202B0008B :103F4C000041002100420016000042029A0000418C :103F5C0000000041000F0044001C00000000410262 :103F6C00AC32410023004100240041000C00410010 :063F7C00200041002200BC :03000B0002494364 :10494300C0E0C0D075D008051DE51D64047037F5BF :104953001D0519E51970020518FFAE18BE0327BF20 :10496300E824751800751900051AE51AB43C177583 :104973001A00051CE51CB43C0D751C00051BE51B4A :0B498300B41803751B00D0D0D0E03248 :00000001FF The locations of the code sections are: hex file addr binary file addr 4C39-4C63 0C39-0C63 wrong 3EAC-3F82 1EAC-1F82 wrong 000B-000D correct 4943-498D correct One translator seemed to work when the tiny code section at 0x000B was moved to the beginning of the hex file. Any ideas or comments will be appreciated.
That's a very old compiler version! (current is 6.14) The current compiler doesn't generate hex; it generates OMF51 Objects, which must be linked to an OMF absolute binary file. You can then use the BIN2HEX binary-to-hex converter utility if you need a hex file. Have you tried downloading the latest Keil BIN2HEX?
my C compiler is 5.20, the uvision is 1.32 the linker generates the hex file so I guess it is really a linker problem? has this been reported before? has it been fixed in some version of the linker or bin2hex? why would the order matter in a hex file?
my C compiler is 5.20, the uvision is 1.32 confusing, isn't it!? but they're still pretty old versions; uVision2 is a great improvement over v1 the linker generates the hex file Not sure about your version, but the current linker does not generate the hex file; when you check 'Create Hex File' in the uVision options, that tells uVision to run the OH51.exe object-to-hex converter on the Linker's (binary) output. has it been fixed in some version of the linker or bin2hex? Dunno. What version of OH51 do you have? Mine is v2.5 (with uVision v2.14 & C51 v6.14 - see the uVision Help/About) why would the order matter in a hex file? It shouldn't, unless you have something which has made some unwarranted dodgy assumption about the ordering within a hexfile...
Some HEX loaders REQUIRE that the HEX file records are in order. However, there is no such requirement from the specification. As such, you may have to sort the records in the HEX file. You can use the sort command in Windows/DOS. Jon
why doesn't Keil make the binary to hex conversion program sort the records so it will work with virtually all emulators and programmers? the dos sort functions with the /+4 ( start sorting with character 4 ) but it also moves the end of file record to the first part of the file
Why should they? The Hex format does not require it. Similarly for Motorola S-Records. As you said yourself, "The hex file seems to meet the Intel hex file specification" The problem is lazy programmers who just assume - without verifying their assumption - that the hex file will be in order. You should complain to your translator vendors who have supplied deficient software which can't cope with well-formed hex files!