| ??? 09/17/03 14:19 Read: times |
#54875 - RE: HEX file merge Responding to: ???'s previous message |
George:
It is my opinion that your suggestion to simply merge HEX files with a text editor is potentially more dangerous than the process of using a Hex to bin and then bin to hex conversion. Here are the reasons. 1) You say that the lines in the hex file are independant. This could be the farthest from the truth in the cases where a line from one input hex file goes from say address N to N+13 and the second input hex file has a line specifying addresses N+4 to N+8. In a text editor seeing this overlap is not reliable!! In a utility program the binary buffer is first initialized to 00's or FF's based upon the target "erased state" and then as hex source material is read in and plugged into the buffer there can be a check for each and every byte to see if an input record is specifying a byte in the binary buffer that already contains data other than the "erased state". If the overlay is detected an error can be shown or other appropriate action taken. 2) Merging of hex data is often done to arrive at a final image for a program to support device or flash chip programming. It is becoming common these days that HEX images are used as the input material to support re-programming of FLASH. In these cases it is normally necessary to have the hex records in the source information file to be in strict order in terms of target device addresses. This is necessary so that the in-target programming algorithm can be written to make straightforward but accurate and efficient decisions of when to erase particular flash blocks without having to have large RAM buffers. (I can discuss this more later if anyone does not understand my point here, but suffice it to say that it is feasible to make an IAP type updater that needs a RAM buffer only as large as a single hex input record as opposed to a buffer big enough to hold a whole FLASH block. 3) A common operation performed during a merge is to insert a program image checksum that then is checked and/or displayed at target code runtime. This insertion usually requires the checksum pre-calculation to be performed across the whole target memory space (including possibly target erased image bytes). This pre-calculation is best performed using a binary buffer representation of the source hex file or files. Michael Karas |
| Topic | Author | Date |
| HEX file merge | 01/01/70 00:00 | |
| RE: HEX file merge | 01/01/70 00:00 | |
| RE: HEX file merge | 01/01/70 00:00 | |
| RE: HEX file merge | 01/01/70 00:00 | |
| RE: HEX file merge | 01/01/70 00:00 | |
| RE: HEX file merge | 01/01/70 00:00 | |
| RE: HEX file merge, to Michael | 01/01/70 00:00 | |
| RE: HEX file merge, to Michael | 01/01/70 00:00 | |
| RE: HEX file merge, to Michael | 01/01/70 00:00 | |
| RE: HEX file merge, to Michael | 01/01/70 00:00 | |
RE: HEX file merge, to Michael | 01/01/70 00:00 | |
| RE: HEX file merge | 01/01/70 00:00 | |
| RE: HEX file merge | 01/01/70 00:00 | |
| RE: HEX file merge | 01/01/70 00:00 | |
| RE: HEX file merge | 01/01/70 00:00 |



