I have Flash EEPROM configuration data file for a faulty Wireless Subsciber terminal unit. I obtained the file by EEPROM Universal Programmer.

I'm convinced that segments of the file are corrupt because the device works if I burn in, with the Programmer, a configuration data file of a working device.

Since each device has unique serial number and other parameters encoded in configuration file, it is improper to program a faulty device with a configuration file of a working device, ie, no two devices must have same serial numbers.

I wish to convert this bad file to asm and edit to reprogram the faulty device, hoping that will get it back to normal operation. I have a rather shallow knowledge about the subject but I'm confident that a detailed systematic procedure would help. Could the hex-ascii display on the eeprom application software and the original compiled hex file be any different? The target is a motorola processor.

Thanks and regards

 

You can either take the file apart by hand with the device's instruction listing as a guide, or perhaps make up or find a disassembler.

 

The EPROM stores both configuration data and machine code. I'll bet the machine code will all be the same and only the configuration data is different. A disassembler will not offer great help in this case.

How the configuration data is arranged might not be easy for one to pick apart and most certainly the manufacturer would try to encode the data to make cloning the EPROM for another unit difficult.

If you know the serial number of the "good" unit, you can use a HEX or binary editor to load both the "bad" file and the "good" file and see if there are any similarities between the two or you can actually see the serial number in "plain view".

I'm afraid that is all you can do.

 

I know the serial numbers for all the devices. I could also use IDM UltraEdit and UltraCompare application software to do comparisons and editing. How do I see the serial numbers in “plain view”? Forgive me, however may I know if each byte of hex code represents an instruction or a stored value or both?

 

I know the serial numbers for all the devices. I could also use IDM UltraEdit and UltraCompare application software to do comparisons and editing. How do I see the serial numbers in “plain view”? Forgive me, however may I know if each byte of hex code represents an instruction or a stored value or both?

You are only lucky if you can see the serial number in plain view. By that I meant the manufacturer has NOT encoded the serial number so it can be seen using just about any binary editor.

There is nothing you can do to make it appear in "plain view".

 

First you will need to compare the two files. Hopefully, only the serial numbers will be different, or at least readily recognizable. They WILL show as ASCII numbers: "1235" will show as "31 32 33 35".

Load BOTH the good and the bad .HEX files into the editor. Go to the line(s) in the bad file with the serial number, and copy the line(s). Go to the same line in the good .HEX file, and make sure the surrounding lines are the same in both files. If so, replace the line(s) in the good .HEX file with the one from the BAD .HEX file.

If you are really screwed, just copy the ASCII serial number from the bad file over the serial number in the good file. Now get out your hex calculator. The Intel Hex format is defined as follows:

Each line of Intel HEX file consists of six parts:

1. Start code, one character, an ASCII colon ':'.
2. Byte count, two hex digits, a number of bytes (hex digit pairs) in the data field. 16 (0x10) or 32 (0x20) bytes of data are the usual compromise values between line length and address overhead.
3. Address, four hex digits, a 16-bit address of the beginning of the memory position for the data. Limited to 64 kilobytes, the limit is worked around by specifying higher bits via additional record types. This address is big endian.
4. Record type, two hex digits, 00 to 05, defining the type of the data field.
5. Data, a sequence of n bytes of the data themselves. 2n hex digits.
6. Checksum, two hex digits - the least significant byte of the two's complement sum of the values of all fields except fields 1 and 6 and checksum byte). It is calculated by adding together the hex-encoded bytes (hex digit pairs), taking only the LSB, and either subtracting the byte from 0x100 or inverting the byte (XORing 0xFF) and adding one (1). The result must then be anded again with 255 since both 0x100-0 and (0x00 xor 0xFF)+1 equal 0x100 and so, if you are not working with 8 bits variables, you must suppress the overflow. If the checksum is correctly calculated, adding all the bytes (the Byte count, both bytes in Address, the Record type, each Data byte and the Checksum) together will always result in a value wherein the least significant byte is zero (0x00).

Take your calculator, and figure out the checksum for the affected line(s). You may first want to practice on a known-good line and replace it with the new checksum.

Good luck!
--Rich
(Gone 'til next year)

 

Thanks Rich,

I'm wondering if the hex-ascii display as seen on the eeprom application software could be different from the original compiled Motorola S hex file format as a result of mapping to different functions by the OP-Code instructions of the EEPROM. If so, could I revert to the original Motorola S hex file format before I do any calculations? I'm terribly stuck on this.

Thanks in advance.