This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Use of hex2bin for legacy project

Hello. I needed to make a firmware change to a legacy project. It is actually generated using TI's code composer, but I'm able to generate a hex file from there.

After reading the forums here and for TI, I see that this is not neccesarily how the program should be used, but I see hex2bin.exe in all previous firmware versions, and mentioned in design notes, though not how to actually use the program.

I am using this post for my research:
http://www.keil.com/support/docs/274.htm

With some experimenting, I have used this command in command prompt:
hex2bin V2AcqSys.hex [V2AcqSys.bin]

I'm not too familiar with this stuff, so I would appreciate any advice you could provide in this unorthodox situation.

Thanks for your time.
-Cam

  • The HEX formats from the late 70's early 80's were designed to transfer 7-bit ASCII records over a serial connection, and provide a convenient way to output sequential byte streams from the linker in a not wholly linear fashion (think interleaved code/data segments). Tools like HEX2BIN, SRECORD and FROMELF, etc can take these HEX formats and convert them to 8-bit binary images, or contiguous/ordered data which reflect how the data is seem be the CPU in ROM/EPROM/FLASH. The .HEX data can also be sparse (have holes), and this empty space is often filled with 0xFF characters, or other convenient patterns, the 0xFF reflecting an unprogrammed EPROM/FLASH cell.

    The format of the .HEX files is very simple, they were designed to be easily parsed by 8-bit processors, often in assembler. Writing C programs to create or manipulate these files is not hard.

    Get yourself a hex editor, or file viewer, and look at the internal contents of .BIN files. Play with STDIO file handling functions.

    How does this impact your firmware, I'm not really sure, the conversion is usually part of the building/linking process, and converting file formats to suit device programming tools or distribution methods. For example if manufacturing used a specific format for a particular EPROM or CPU programmer/burner, or if 16-bit data needs to be split between two ROM devices. Today's Universal Programmers might be significantly more flexible about the files they can handle.