I get an error when I try importing an intel hex file in to version 2.5.0.0. The intel hex file only a few K big was auto generated and looks to be correct.
Error XmlHexImporter.pas, line 651
Importing Intel Hex
Importing Intel Hex
- Attachments
-
- hdx intel hex import error.JPG (17.03 KiB) Viewed 13055 times
Re: Importing Intel Hex
Please provide the file, otherwise it's impossible to fix the error.
Re: Importing Intel Hex
The problem seems to be that the last 2 lines in the file are
:000D9A0158
:00000001FF
These line were generated by the compiler.
If I remove them, then the data part of the file loads okay
I hope this will give you enough information.
:000D9A0158
:00000001FF
These line were generated by the compiler.
If I remove them, then the data part of the file loads okay
I hope this will give you enough information.
Re: Importing Intel Hex
If you look at the official documentation of the Intel Hex file format, you will see that it mentions the end of file record (last page of the PDF above).
The following of your two records has a RECTYPE of Which makes it an end of file record.
And as the official Intel documentation states for EOF records:
The assertion error in HxD is a safety measure to detect invalid files and unexpected data. It's not a bug in HxD, but I suppose you could ignore this file format error, without too much harm. At least for reading it makes no difference.
Your Intel Hex file ends with two EOF records, the first one cited above is strictly speaking incorrect, even if you could say the load offset will most likely be ignored by most software. After that a second EOF record follows, which should never happen. Both these issues should be addressed in the software generating the file, since it might hint at other issues (though probably just too generic coding).
It would be a good idea to point out these errors to the compiler manufacturer.
The following of your two records has a RECTYPE of
01
:
Code: Select all
:000D9A0158
^^
And as the official Intel documentation states for EOF records:
In other words the load offset should be zero. But since it is not used, I suppose you could ignore it.LOAD OFFSET -- This field contains 030303030H, the hexadecimal encoding of the ASCII characters ’0000’, since this field is not used for this record.
The assertion error in HxD is a safety measure to detect invalid files and unexpected data. It's not a bug in HxD, but I suppose you could ignore this file format error, without too much harm. At least for reading it makes no difference.
Your Intel Hex file ends with two EOF records, the first one cited above is strictly speaking incorrect, even if you could say the load offset will most likely be ignored by most software. After that a second EOF record follows, which should never happen. Both these issues should be addressed in the software generating the file, since it might hint at other issues (though probably just too generic coding).
It would be a good idea to point out these errors to the compiler manufacturer.
Re: Importing Intel Hex
I edited the post again, please see the updates.
I will see if I can "fix" this without any harm.
I will see if I can "fix" this without any harm.
Re: Importing Intel Hex
Could make this a warning instead of an error, at least it would load and display the data.
Thanks
Thanks
Re: Importing Intel Hex
I'll see what I can do, but the current architecture has no way to provide warnings in the GUI (would need an extra log window) and the class that implements this has no facility to report anything but errors and success, but I'll see what I can do.
Still, please point out this bug to the manufacturer, because a correct file should just have one EOF record.
Still, please point out this bug to the manufacturer, because a correct file should just have one EOF record.
Re: Importing Intel Hex
I reviewed the entire logic, and it will not affect the result, if I add some countermeasures.
So the importer now ignores these two types of file format errors safely and therefore silently.
Solved in current development version.
So the importer now ignores these two types of file format errors safely and therefore silently.
Solved in current development version.