General question about Bootloaders and .hex/.bin files

[bjerman]

Posted on August 19, 2015 at 14:01

Greetings,

I have a very general question regarding using an external uC, an EEPROM and an ethernet PHY IC to implement a reflash-through-ethernet capability on a custom board.My question is about the program data that the compiler produces and stores into a .hex or a .bin file. The usecase I'm looking at is feeding one of these two files into an PC-based application which would fragment the raw machine code and send it through ethernet to the module which is being upgraded and the difference between the two file types.As far as I understand, the .hex file contains a set of ASCII characters which represent hexadecimal values, whereas two consecutive characters represent a byte to be written into the uC program memory. Every line in a .hex file ends with an ASCII characters for a newline and the new line is preceded by a ASCII character '':''The question here is: Is my understanding correct, and are there any superfluous characters or padding which should not be parsed by the application which job it is to extract the raw programming bytes which are to be sent to the module and then uploaded into the uC program memory. The specific compiler being used is gcc.As far as .bin files go, it's my understanding that they contain raw hexadecimal values of the intended program, without any ASCII delimiters or superfluous symbols. Case in point, the question here is:Can the PC-based application simply read the .bin file and expect all bytes  within to be valid for the write into the program memory of the uC, without any external parsing.The application is not required to make the code user-readable, so just feeding it the .bin file and then picking up from there would be the best option. What I'm trying to ask is if my understanding of the file formats is correct, so I reduce the chance I could run into any problems down the road. It's my first time doing something like this.

[Tesla DeLorean]

Posted on August 19, 2015 at 15:02

Correct, the .BIN represents the linear memory image in bytes that's loaded into the processor memory and executed. It appears in the file, as it does in memory, the base address of the image has to be inferred from knowledge of the processor and the way the file was created.

The .HEX file specifies bytes and addresses within the micro they need to be written. The file can be sparse (have holes), and be non-linear/contiguous (out of order). The lines also have checksums to help ensure the integrity, as the 7-bit ASCII representation was designed to be sent over old serial links, or processed by different equipment and micros.The Intel .HEX format has been in use for many decades, there's a lot of good documentation about it, and it's not a particularly complex format. ie easily decoded using 8-bit assembler code.

[bjerman]

Posted on August 19, 2015 at 16:39

Thank you for your prompt reply.

This is the third time I've received invaluable help from you, specifically, on these forums. It's very much appreciated.