Intel Hex File viewer/editor

[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...

[brucehoult]

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.

To be fair, it's impossible to do much better using small fixed width instructions.

Ideally, you'd like to be able to specify two registers (5 bits each on 12 bit PIC, 7 on 14 bit, 8 on 18 bit) or one register and a constant, one of the 10 sensible comparisons (4 bits), and a decent branch offset (9 bits on 12 bit PIC, 11 on 14 bit, 14 on 18 bit).  Add those up and you get that to do that in one instruction you need 32 bit instructions like RISC-V.

With 12 bit instructions you really don't have any choice but to do...

Code: [Select]

load reg
cmp reg (or sub)
skip <cond>
jump <offset>

... which is exactly what PIC has.

I can't see that the 8051 is any better.  To do what is a single instruction "BLT i,j,label" on a RISC with 32 bit opcodes you need ...

Code: [Select]

mov a,i
clr c
subb a,j
jc label

... which is still four instructions, but you only have 8 registers available, not 32-256 like on PIC, so it's quite likely you're going to need to load the values you want to compare into registers first.

The 8051 does have the luxury of both 1-byte and 2-byte instructions so you can for example subtract a constant from A with one 2-byte instruction, and the conditional jump uses a 2nd byte for the offset.

Similar for z80.  Once again you only have 7 registers other than A (11 counting the very slow IX and IY halves), and you have multi-byte instructions. Also, there is a CMP that doesn't need you to fiddle with the carry first. The Z80 does allow you to load from a memory address directly into A, or load a constant into any register. But it's really not any better than the PIC.

The most useful thing on the Z80 is the 16 bit operations, though they mostlty only save code size, not cycles.

[DavidAlfa]

HxD can import hex files

[MathWizard]

I've been making AVR opcodes and IntelHex in a spreadsheet lately, and OpenOffice has problems with copy/paste sometimes, and numbers/letters get snipped. And it's not fully automated, I have to copy/paste the intelhex headers, and single opcodes, all together.

I should use an actual compiler, or even try writing a C program for it. But I'm doing a lot of stuff in the speadsheet, besides making single opcodes.

I've tried a couple of hex viewers, I'll give the OP's a try too.