Intel Hex File viewer/editor

[forrestc]

I occasionally (like right now) need to dig into an Intel Hex file.   Although I can open it up in a text editor and read it manually, I would rather use a tool intended for this purpose.

Does anyone know of a tool which is designed for this?

One note:  I have had luck over the years loading these into various programming tools and viewing the resulting hex image.  The problem with this hex file in particular is that it apparently has generated data outside the address range that the tool I'd normally use, which is why I need to dig into this with something else.  Unfortunately, this is a very large .hex file so I'm having problems finding the problem.  I might end up just writing some code to find the error, but would rather not go to those lengths.

[bingo600]

I occasionally (like right now) need to dig into an Intel Hex file.   Although I can open it up in a text editor and read it manually, I would rather use a tool intended for this purpose.

Does anyone know of a tool which is designed for this?

One note:  I have had luck over the years loading these into various programming tools and viewing the resulting hex image.  The problem with this hex file in particular is that it apparently has generated data outside the address range that the tool I'd normally use, which is why I need to dig into this with something else.  Unfortunately, this is a very large .hex file so I'm having problems finding the problem.  I might end up just writing some code to find the error, but would rather not go to those lengths.

Convert it to binary (srectools)
http://srecord.sourceforge.net/

Use a standard hex file editor , and convert it back (srectools)

/Bingo

[leeatljs]

Tiny Hexer from http://www.mirkes.de/ imports / exports intel hex, allows editing, comparing, all sorts of stuff.
Is also a general hex editor.
Does Motorola S records too.

[voltsandjolts]

You could just use the application software for a device programmer.

e.g. Galep software in demo mode does what you want http://www.conitec.net/hardware/down/G5setup_20638.exe

[stj]

i like this:
http://sweetscape.com/

[timb]

 I made a custom grammar file for Synalyze It! Pro, which is a very slick macOS hex editor. (It's in the Mac App Store, fairly expensive but you can also get the non-pro version for $10, which will work for the majority of users.)

There's also a sister application for Windows/Linux that uses the same grammar files. It's called Hexinator.

[free_electron]

You could just use the application software for a device programmer.

e.g. Galep software in demo mode does what you want http://www.conitec.net/hardware/down/G5setup_20638.exe

jup. best option. get the control software for a dataman programmer. those can run in demo mode. load hex file, edit , save back as hex file.

[ehughes]

http://www.hexworkshop.com/

[HwAoRrDk]

Tiny Hexer from http://www.mirkes.de/ imports / exports intel hex, allows editing, comparing, all sorts of stuff.
Is also a general hex editor.
Does Motorola S records too.

While Tiny Hexer is a great program, and does do that, don't download it from that link. The original author shut down his website years ago and what exists now is just a scummy domain holding page full of ads.

Best place to find and download it is from a shareware/freeware archive site. And even then be very careful.

[newbrain]

If you happen to like Emacs, there's this.
It shows the address (while in data) or the field type you are on on the mode line, and can recalculate the checksum after editing.

[jesuscf]

Quartus II Prime also comes with a nice Intel-Hex editor.  Of course, only if you have it installed already as it is quite a big program.

[jesuscf]

Just came across this one:

http://www.catch22.net/software/hexedit

Looks nice and includes source code:

http://github.com/strobejb/HexEdit

[andy1]

There is also Kaitai Struct http://kaitai.io/ with which can quite quickly code a parser for this kind of reading, also has visualizer which can open the file and show the structures like in hex editor or you can just make a nice python etc. parser with it.

[wraper]

Most of the "HEX" editors suggested certainly are pretty useless for editing intel HEX. Even if they can import/export intel HEX, they do it in crippled way. They will shift data address space to make start address being 0, although it wasn't in the original file and will fill any empty address space too. The result of it will be a useless file which cannot be programmed to target device.

[0xdeadbeef]

Also note that a hex file of an 32bit controller can result in a BIN file of 4Gigabyte. A typical hex editor will fill all the gaps with zeroes, even the initial gap, if e.g. the first data is located at address 0x40000000.
This quickly results in unusable crap. Then again, for typical microcontroller stuff where the 1st flash block starts at 0, this might be not an issue.

[forrestc]

Also note that a hex file of an 32bit controller can result in a BIN file of 4Gigabyte. A typical hex editor will fill all the gaps with zeroes, even the initial gap, if e.g. the first data is located at address 0x40000000.
This quickly results in unusable crap. Then again, for typical microcontroller stuff where the 1st flash block starts at 0, this might be not an issue.

When I originally asked the question, I really was hoping to find effectively a 'sparse file editor'.   I.E. one which works like a hex editor, but only shows lines/addresses which actually exist in the file.   I'm still hopeful.   But I agree - a 'traditional' hex file editor, even one which will read Intel HEX files correctly are not that useful.

I did come across the srecord tools which solved my immediate need - getting a list of all of the ranges which were covered in the .hex file.  I was able to compare these ranges to the memory map of my device and find the mangled linker file which was filling some nonexistent addresses with 0xff's.  Depending on the editor, this may have been invisible - since some editors choose to use 0xff as the fill value instead of 0x00.  Not to mention that this area was up around 0x1FC00000, with other data scattered all around the 4GB memory map - so I would have had a lot of fun finding this needle in the haystack.



 

[legacy]

Depending on the editor, this may have been invisible

why don't you write by yourself ?
custom need, custom tool

[forrestc]

Depending on the editor, this may have been invisible

why don't you write by yourself ?
custom need, custom tool

Sorry, just catching up on my posts, been traveling....

Actually this isn't a custom need.   The definition of what I'm looking for is a editor which will open a .hex file, interpret it, and then allow you to view/edit it, without making up data in the process.  This should be something at least a good portion of those who work with .hex files should want/need.

The problem is that the existing tools I've found seem to not work that well for this purpose, specifically because instead of showing only what is in the hex file, they choose to create a very large virtual memory space, fill it with either 0xff or 0x00, and then load the data from the hex file into it.   This effectively creates data which doesn't exist.  Many hex files simply don't include data for the entire memory space of a part, or for many parts, the valid memory space itself isn't contiguous.   Most programming tools which allow you to load .hex files and view/edit it will show you the resulting data they would program - not the exact data included in the .hex file.

So, the tool that is needed is a gui editor for a .hex file which understands the meaning of the .hex file and preserves it.   If the hex file contains 3-4 non-contiguous segments, the editor should display only the data contained in the .hex file, not make up data which isn't contained in the .hex file.

[jpittner]

It should be possible to use objcopy (cross-version like arm-elf/objcopy etc.) to convert the ihex back to elf object file format for given architecture and than use cross-version of objdump to display memory sections, disassemble etc. According to man page, objcopy should be able to convert between any two formats. I gave it a quick test on AVR:
avr-objcopy -O elf32-avr -I ihex project.hex test.out
file test.out
test.out: ELF 32-bit LSB relocatable, Atmel AVR 8-bit, version 1 (SYSV), stripped
avr-objdump -D test.out
...gives assembly section by section

[micha2070]

try: https://github.com/micha2070/intelHex

[baldrick9]

Good ol' Notepad++ shows Intel Hex colour coded 'n all! - https://notepad-plus-plus.org/

[brucehoult]

It should be possible to use objcopy (cross-version like arm-elf/objcopy etc.) to convert the ihex back to elf object file format for given architecture and than use cross-version of objdump to display memory sections, disassemble etc. According to man page, objcopy should be able to convert between any two formats. I gave it a quick test on AVR:
avr-objcopy -O elf32-avr -I ihex project.hex test.out
file test.out
test.out: ELF 32-bit LSB relocatable, Atmel AVR 8-bit, version 1 (SYSV), stripped
avr-objdump -D test.out
...gives assembly section by section

There's no need for that -- objdump recognizes and uses hex files automatically. You only need to tell it what ISA to disassemble e.g.

Code: [Select]

riscv64-unknown-elf-objdump -m riscv -D foo.hex

[SiliconWizard]

Also, on Windows, I use HxD, which can open binary files and import Hex and S-rec files as well.

https://mh-nexus.de/en/hxd/

[wraper]

Also, on Windows, I use HxD, which can open binary files and import Hex and S-rec files as well.

https://mh-nexus.de/en/hxd/

It can open it, yes. The problem with that was already mentioned many times. It will simply fill empty address spaces, which makes in completely unusable for editing in most cases when there is actually a reason for using intel hex.

[MustardMan]

Was a solution to this problem ever found?

I have the same problem... wanting to edit a HEX file (not a BINary file) without expanding it.

Notepad++ sure does nice colouring of a HEX file, but it shows nothing of the contents. I want it to look like a BINary file editor with the HEX on the left and the BIN on the right. But I don't want to have to expand my HEX to BIN to do so. As was so correctly pointed out, many HEX files contain stuff with large segments of unused memory, one-liners with interrupt vector entries etc, and some with address ranges outside the memory map.

The problem I've been running into is that most people call binary editors 'hex editors' so google searches are next to useless.

Did the suggestion (by micha2070) of  https://github.com/micha2070/intelHex work? I don't want to install more bloatware (java) simply to try this and find it is just like every other binary file editor out there.

In my searching I did come across a program called "HEXit" by HSE electronics, but the licencing model looks way over the top for something that should be quite a simple program, so I have not tried it.

Cheers, MM

[free_electron]

simply download the control software for any kind of eprom or device programmer. Dataman , Hilo systems you name it. This software runs without the programmer attached. They can open any kind of intel , motorola and many other formats. They all have an editor on board that can show you the content and lets you edit it. you can join/merge 8 16 32 bit files and many more specialized functions you will not find in any other kind of general purpose editor. and you can save back to format of your choice

[ndzied1]

It is a pay program but I believe Ultraedit will do what you want.

[0xdeadbeef]

UltraEdit just has a (basic) hex editor mode to display/edit the current file in a raw data view. I'd be honestly surprised if it even had an import functions for Intel hex files. I'm pretty sure it hasn't. After all, it's a text editor by trade.

Of course there are tons of hex editors out there which allow loading from and saving to different text file formats (Intel hex, Motorola S-records). But as discussed before, they will typically load a hex file into a default memory range that starts at 0 and ends after the last byte of the hex file. So 32bit ranges are problematic and storing the hex file again will either store one big chunk or you need to save ranges specifically and merge them later.

But my understanding still is that the OP was looking for a tool that would allow editing the specific ranges inside a hex file and then automatically also saving only the exiting/edited memory ranges.
AFAIK none of the major commercial hex editors offers this feature. And while it's certainly feasible to keep data in editable chunks, I would think it's quite a bit of additional effort to do it right. E.g. the editor would need to keep track of a potentially unlimited (worst case: chunks = filesize/bytes per line) number of chunks of data, split/merge them dynamically if needed, consider fill patterns correctly etc. Which is probably why it wasn't done yet (AFAIK).
Of course the typical scenario with one chunk of data at some start address would just make it necessary to remember the start offset somewhere (comment, additional file) and apply it when saving. This should be easy to implement, but would be a bit of a hack.

[Ian.M]

The command line HEXMATE utility (bundled with Microchip XC8 and legacy Hi-Tech C compilers) can be used to do all sorts of stuff with IntelHEX files, including splitting up a hex file, reporting how many data bytes are in a particular address range, or in the whole file, finding stuff within a hex file and patching it or patching at a fixed address, and also normalizing the hex file format.  See https://manualsbrain.com/en/manuals/613210/?page=303 for a preview of how to use it.

[free_electron]

again, get the control software for a device programmer. it is free. and you can do all that offset , 8 16 32 bit merging / splitting , relocating. It is made for that purpose.

https://www.dataman.com/dataman-48pro-resources

https://www.hilosystems.com.tw/en/support-mmenu-en#

http://www.logicaldevices.com/download/default.html

any of those will do

[0xdeadbeef]

Tried the first one and it was exactly as I imagined. Letting aside its permanent desire to connect to a supported programmer, when loading a MOT with an offset, it created an address range starting at 0.
So honestly I don't how this would be superior to a proper hex editor or fulfill the requirement to keep track of the used memory ranges to only save these automatically.

[free_electron]

does your file contain the offset record ? and if so , is it at the BEGINNING of the file ?

[0xdeadbeef]

Nope but this kinda shows that - if at all - these tools could handle one chunk at a start offset. At discussed before, this would be the easy part. In a 32bit address range, you could have multiple chunks distributed over the whole address range (well, admittedly flash typically is located in the first few MB, but for sure there are systems with larger gaps).

[PCB.Wiz]

So honestly I don't how this would be superior to a proper hex editor or fulfill the requirement to keep track of the used memory ranges to only save these automatically.

If you want to preserve the ranges, that should also include out-of-order too ?
That's such a specialized niche, you may need to write your own, or make a python script that actually looks into the hex data, for the real info you are after.
HEX files are universally generated by machines, so comprehensive manual editing is going to be very rare.

[free_electron]

Nope but this kinda shows that - if at all - these tools could handle one chunk at a start offset. At discussed before, this would be the easy part. In a 32bit address range, you could have multiple chunks distributed over the whole address range (well, admittedly flash typically is located in the first few MB, but for sure there are systems with larger gaps).

The problem is not the tools. The problem is that stupid motorola format ! you are most likely dealing with S3 ( 32 bit address ) . The addresses are hardcoded in the record itself. The eprom programmer tools should be able to apply an offset ( they can join multiple binaries into one rom. you can specify the 'begin' address and this is added to the address in the record..

When saving back there is an option to not write out the chunks that contain all 0x00 or 0xff ( you need to tell what is 'empty space' )

[MustardMan]

I'll give HEXMATE (recommended by Ian.M) a try.

I suppose what I am looking for (like the OP) is essentially a text editor, and notepad++ is certainly a good start. Maybe could be coaxed into...

Display the file, as it is formatted in the original (eg: intel hex) file, nice colouring for the record type, address, data & checksum - all shown as hexadecimal 00 to FF
Display the data only portion as ASCII tabbed into a new column
Ability to edit either the hexadecimal or the ASCII
Ability to delete & insert lines : delete easy, insert harder as follow-on addresses would need to ripple (or be overwritten when the hex file is loaded into memory - maybe desired!).
On exit recalculate the checksum for every line

Just like binary editors do with contiguous chunks (but without forcing me into working with contiguous chunks)

Cheers, MM

[Ian.M]

I must *EMPHASISE*  HEXMATE is entirely a command line tool.  Its not even as minimally interactive as DOS EDLIN!   You could use it to build a valid IntelHEX file line by line but it would be a mighty clumsy and painful process.  Its best used *AFTER* determining what needs changing, to automate the process of patching the file.

[Peabody]

MustardMan, have you tried HxD?  It's free, and in a recent update he added support for hex files.  You can *import* a hex file, and it converts that to hex at the proper locations in the 16-bit (or larger) address space.  It doesn't show the checksums, and you can insert and delete all you want.  Then you *export* as a hex file.  It's only then that it calculates the checksums.

If you select a block, it will export only the block.   Otherwise it exports everything.  It shows undefined portions of the address space as all zeros, which is unfortunate, and I don't see an option to make them FF.  Anyway, even if it exports too much, you can always bring up the resulting hex file in a text editor, and just delete the unneeded lines.

There's also an option setting for the number of bytes per line in the exported file.

Anyway, you might want to look at it.

https://mh-nexus.de/en/

[MustardMan]

Thanks for the tip Peabody.

I had an older version of HxD that didn't import/export hex files, but I have just tried the latest version and it looks good. Apart from filling "unaddressed memory" with zero, it does very well. My specific use case is I would like to search for a string in the hex file (as ASCII), replace it, and rewrite the hex file. The ability to edit either the ASCII or the HEX (which most binary editors also do) is really a must-have for such an editor.

The target of interest is a PIC microcontroller with 14 bit instructions, and the problems I am encountering are -
1] The HEX file is organised as 16 bit byte pairs, so searching for ASCII constants is not easy as in the 'decoded' section the bytes of interest (the constants) are all spaced out, appearing as double bytes.
2] The HEX file does not fill the entire address range, but everything I've tried so far pads the file/data/memory out to the maximum address, and in the case of the PIC, that range extends to a few bytes beyond the logical address range (where the configuration words are stored). Hence saving gives me a big file with mostly zeros. I suspect specifying and saving a 'block' as you say would miss the trailing bytes, so saving the whole lot and then using a text editor after other operations have been performed is the work-around.

Once again, thanks for the HxD tip.

MM

[free_electron]

Thanks for the tip Peabody.

I had an older version of HxD that didn't import/export hex files, but I have just tried the latest version and it looks good. Apart from filling "unaddressed memory" with zero, it does very well. My specific use case is I would like to search for a string in the hex file (as ASCII), replace it, and rewrite the hex file. The ability to edit either the ASCII or the HEX (which most binary editors also do) is really a must-have for such an editor.

The target of interest is a PIC microcontroller with 14 bit instructions, and the problems I am encountering are -
1] The HEX file is organised as 16 bit byte pairs, so searching for ASCII constants is not easy as in the 'decoded' section the bytes of interest (the constants) are all spaced out, appearing as double bytes.
2] The HEX file does not fill the entire address range, but everything I've tried so far pads the file/data/memory out to the maximum address, and in the case of the PIC, that range extends to a few bytes beyond the logical address range (where the configuration words are stored). Hence saving gives me a big file with mostly zeros. I suspect specifying and saving a 'block' as you say would miss the trailing bytes, so saving the whole lot and then using a text editor after other operations have been performed is the work-around.

Once again, thanks for the HxD tip.

MM

ahhh, now the cat is out of the bag. and you blame the tools ? blame that fucking PIC nonsense !

[Ian.M]

*IF* its a product of one of Microchip's C compilers the upper six bits of a word encoding a character in a string are quite predictable and will normally be a RETLW opcode.  Knowing that, searching for the string shouldn't be too difficult.  e.g. Hexmate can search for up to eight bytes and even mask out the OPCODE in the high bits, so you can use it to search for your string, four characters at a time.

[MustardMan]

@free_electron
Yup! That made me laugh!

I agree that the PIC architecture _truly_ sux. Their newer products are a little more sensible, but the older stuff (and the newer stuff that is made to be compatible with the old stuff) is horrible. I learnt micros on a Z80, and then moved to MCS51. They were both very nice architectures.
Then I changed jobs and started work at a place where PIC was king. By god it was a shock... how could anyone design such a POS? The workplace had obviously gone for lowest entry cost, regardless of any sensibility.

However, sucky architecture aside, they do make some very nice hardware (ie: peripherals), and an excellent (although confusing) array of chip variants from 6 pin to well over 100 pin, DIP to BGA.

Fortunately their tools hide most of that very ugly underbelly. I wonder if their software developers have any hair left? Or maybe they all committed suicide...