Comments (11)
Can You provide an example of a file before encode and after decode?
If i understood correctly (from the "fix" code) to have your image written correctly You must put first line at one before last position. I'm guessing that this is a Starting Address record. IntelHex standard doesn't say strictly about position. It can be placed at the beginning, it can be placed at the end (before End of File record). It could be placed between data segments as well. But this is just my theory - honestly I never seen such Hex file. Nevertheless this IntelHex implementation always place Starting Address record at the beginning of the file.
By the way, Your "fix" code can be simplified:
file = open(output_file_name, 'r')
lines = file.readlines()
file.close()
output = open(output_file_name, 'w')
lines.insert(-1, lines[0])
for line in lines[1:]:
output.write(line)
output.close()
Of course if I clearly read out your intentions. But same is what You get when You run your code.
from intelhex.
I looked at the IntelHex standard again, and I realized that Starting Address record types are numbered higher then Data and Extended Adress records. So maybe this implementation isn't that good after all.
But first let us check the root-cause of your problem.
from intelhex.
IntelHex startard allows separate records to be freely swapped until they all within one 64K page IIRC. Additional starting records can appear anywhere in the file.
Anyway, in your approach I would not rely on MD5 hashing of binary file. With IntelHex files this is not stable approach.
You can use hexdiff.py utility to actually compare content of 2 files, if you wish.
Or maybe you can provide some minimal example of your files with different MD5 before and after processing. It's possible that starting address record is to blame here. I don't really need your binary files, you can inspect with text editor first and last lines and show first 8 bytes here.
BTW the very last line must be EOF record always. So puting it to the start - sounds very wrong. Without real data it's hard to tell what's wrong actually.
from intelhex.
Thanks for looking in to this. Our images are over that size boundary (about 100K), unfortunately I cannot share the hex files here, but I have used hex files with swapped lines in the past when merging in bootloaders in the image. The reasoning behind using the MD5 is because my firmware guy wants that to be used (not my choice). When I diff the files I can see exactly the line that gets swapped. I will get together a small snippet of the beginning and the end of the files to show you what is happening.
from intelhex.
Source File on the Right. Reconstructed on the Left
from intelhex.
Yes, that is the Start Linear Address record all right.
As I already wrote. Current implementation always places Starting Address records at beginning. So no matter where it will be placed when importing a file (e.g. using 'loadhex') You will have always Starting Address record at the beginning of the file when exporting to a file (e.g. using 'write_hex_file').
from intelhex.
"the data is stored in a database as a JSON record" - why don't you save actual hex file content to database then?
from intelhex.
I will change the title of this issue. It can be fixed with another option of write_hex_file, oh my. That's already too complex.
from intelhex.
"the data is stored in a database as a JSON record" - why don't you save actual hex file content to database then?
I'm starting to think I should just do that... This module is very nice though. There is talk of changing bootloaders, so being able to merge the files with this module without manually creating new releases seems like nice future proofing
from intelhex.
Yes, that is the Start Linear Address record all right.
As I already wrote. Current implementation always places Starting Address records at beginning. So no matter where it will be placed when importing a file (e.g. using 'loadhex') You will have always Starting Address record at the beginning of the file when exporting to a file (e.g. using 'write_hex_file').
Im not sure why this is happening, this was compiled and linked in IAR EWARM
from intelhex.
Why You have in Your Hex file Start Record on the end? Probably by a software design. @bialix already wrote that there isn't only one place to put that record. IntelHex documentation doesn't describe this precisely.
It can be fixed with another option of write_hex_file, oh my. That's already too complex.
Yeah. This function is really evolving very dynamically ;)
I thinking about the solution. I see 2 ways:
- We only care about importing and when loading we only check were it's placed, on beginning or at the end. If somewhere else then I suggest to just force 'on beginning' option in this case. And when writing we set it as-is (resolved while loading)
- Option 1. + new parameter, that would replace 'write_start_addr' (in 'write_hex_file' function) with for example 'start_addr_mode', which would have 3 options:
- 'sof' - start of file, old behavior when 'write_start_addr'=True
- 'eof' - end of file, naturally before EOF record
- 'none' - old behavior when 'write_start_addr'=False
from intelhex.
Related Issues (20)
- Can you add hex file support for TI C28x DSP? HOT 7
- TypeError while loading from TemporaryFile (Python 3) HOT 2
- hexdiff.py not working on Ubuntu 19.10 HOT 7
- The binary limitation of bin2hex is 4Kbytes. HOT 3
- Option to insert 'Extended Segment Address' record type instead of 'Extended Linear Address' HOT 6
- tostring bug when using Python 3.9 HOT 14
- Merge fails on two IntelHex16bit files... HOT 1
- A [0:0] slice will return the entire contents, when it should return a empty object HOT 1
- Array attribute HOT 2
- list(ih) causes the Python interpreter to hang up HOT 1
- Is it possible to get rid of those padding byte in list(ih)? HOT 8
- padding byte not retained in slices HOT 1
- Check two IntelHex objects equality HOT 7
- intelhex hangs on using `in` operator HOT 2
- CS:IP entry point calculation seems to be incorrect HOT 2
- Swapping of bytes HOT 2
- bin2hex.py adds extra random byte HOT 2
- Search doesn't appear to work on the readthedocs site.
- Documentation for hex2bin function is not generated.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from intelhex.