Is there an industry standard name for the hex file output format Keil uses for an 8051? In the target configuration, its called "HEX-80", but I'm not so sure that's the official name for this format. Any help appreciated.
I wish this were a "kitchen table" programmer...then there'd be an acceptable excuse. Problem is, this is a production Data I/O Promaster 2500, and the damned thing simply WILL NOT LOAD a hex file. Same hex file I can get any number of other programmers to load without a hitch, including kitchen table ones too ;) If you use the programmed to read a "master" device, then save a hex file from that, then you can read that file back in. But guess what? Insptection of that file shows some unreadable garbage prepended and appended to the file. Huh? Well, thanks all for the info. I've concluded its not our hex files. Beware!!!
are you sure it want a .hex file? did it work once maybe it want a binary Erik
From what I recall the term HEX file does not ALWAYS mean the Intel HEX file. There was a Textronix HEX File or some other HEX file format that was popular for a while. Jon
The source files are, by inspection and by confirmation with a lab BP-Microsystem, a HEX file. Its the file Keil produces from a build. Its the file the BP has no problem burning into a device (Philips P89C664), Yet, when specifying this as the source file for the Data I/O's "task", it bombs telling us there's a checksum mismatch. Inspection of the internal buffer shows it to have corrupted the reset vector (at least) and who knows what else. Mr. Malund brought up an interesting point about the "sequenctial-ness" of the HEX file: The HEX files this thing WILL read come from a master device and are, of course, the entire 64K...sequentially. The original source hex, however, is not sequential and only contains records that require programming. I'm wondering if that may be the problem (err...retardation) of the Data I/O machine??? If it is, tho, it doesn't do us much good because I really don't want to further complicate our build process with yet another data massaging utility that will require verification. What a frustrating mess >:(
Robert, Although it will further complicate the build process, there's probably a pretty easy way to do the whole verification dance. There are various utilities floating around (some even made by Keil, I believe) that will convert a hex file to a "binary image" of what the buffer from the hex file will look like. You could run that on the hex. Next, you can run the inverse (bin2hex) and convert that image into a hex file. Unlike the compiler, it won't have any reason to make something non-sequential and you should have a file that the Data-I/O will use. As far as verifying, you could just run hex2bin AGAIN on the next hex file, and compare that binary image with the one generated from the original hex file. If they're byte-for-byte identical, then there's no further verification needed. Hope that helps.
We use the Data I/O and have found that the files do indeed need to be in ascending order. (Obviously they gave the junior programmer the task of loading the files) Fortunately, the Data I/O is insensitive to the end of file record. You can use the DOS sort command in your build process and everything will be fine.
Bob, Neat trick but I doubt that it would work if the file contains record types 02 or 04. Am I right? -Walt
We use the Data I/O and have found that the files do indeed need to be in ascending order. (Obviously they gave the junior programmer the task of loading the files) Bob, Thanks for the info. I confirmed this with our Mfg'ng, but only with a file that's not only ascending ordered, but also 100% full (i.e. all 64K of space, whether or not programmed, has a record). My question is: If a file arranges its records in ascending order, but there's portions missing (i.e. that don't require programming), does the Data I/O have trouble with this?
Have you tried the fill byte option of the output tab? It will fill all unused space with the specified value. Not sure but it may also order the records. -Walt
Have you tried the fill byte option of the output tab? It will fill all unused space with the specified value. Not sure but it may also order the records. I'm looking at the output tab in the target build properties dialog box and I don't see a fill byte option. Am I looking in the wrong area?
You are looking in the right area. I use the C166 but I would think that feature is common to all tool chains. Perhaps not. Here it is documented for the C166. http://www.keil.com/support/man/docs/oh166/oh166_using_uv.asp -Walt
No. That area of config in uV for the 8051 doesn't look anything like that. All it provides is a "Create HEX File" checkbox and a "HEX Format" droplist with only one choice: HEX-80. Hmmm...would be nice to see the 166 options in the 51 IDE. Anyway, thanks to all for your help. I've nailed the problem down and now, at least, have a direction to persue.
When you are using the LX51 Extended Linker/Locater (which is part of the PK51 Kit) you have more options. Reinhard
I checked and we do have PK51. To test, I checked the "Used Extended Linker (LX51)" option in the Device tab and while the Output tab then offered the additional HEX-386 in the drop list, it did not offer any controls where buffer fill could be specified.