.hex and .bin output files

[Kisen]

Hi,

I am working on a secure bootloader for a device i am creating.

Firmware updates will be obtained from an online server that the device will have access to. However this file will require some signing etc to ensure it is legitimate.
I have seen in the file outputs that there is both a .hex and a .bin file.

I am aware that a .bin is essentially an image of the memory and if provided with a start location the bin file can be copied in as is.
The .hex having location data within it means that i need to keep checking for these locations and program accordingly.

Clearly the .bin is a cleaner approach. However...The .bin file in the output is unreadable., but i would like to be able to verify its content as well as work out how i am going to take this file from the internet and extract it byte by byte into flash memory.

I have seen that you guys use bootloaders in some of your commercial products. What file format and method do you guys use to load the data?
Is it possible to directly stream a .bin file into a device and store each byte in a string for processing?

[Benj]

Hello,

We usually use .hex just because that's what the compiler often outputs. We also use bin files on some devices for the same reason.

A .hex file has a checksum on every line. For a .bin file you would have to make your own checksum by running a mathematical process on each byte or pair of bytes and supplied seperate from the .bin file. If the checksum is the same as expected then you know you can safely program the file.

This only checks that the data is correct as expected. It does nothing to confirm it's for the right device unless you build in a device code as well as the data to the checksum. A simple checksum is to take each value and XOR it with the next.

checksum = DeviceCode
checksum = checksum XOR data0
checksum = checksum XOR data1
...

[Kisen]

For my needs the checksum for the line would be all i need i think.

I am happy to use the .hex, but it takes up more space putting the .hex into a temporary flash memory due to locations, checksums and bytecounts. This specifically isnt an issue since we can just increase the external flash memory and copy it in like for like.
putting it into the external flash would require only checksum verification to ensure it was correct...

Once its in the external flash then a handler could work it all out and put that data into the STM32 flash memory...

I specifically need to add a hash and a signature although not sure quite how to go about this just yet. This is a security measure to ensure that the firmware came from me.

I assume i can add this data into a .hex file?
Essentially this would be added in prior to the actual HEX data almost like a header file of sorts.

[Kisen]

I have just re-familiarised myself with the intel hex format.
I have come across this line in the .hex file. It is just before the last line.

Code: Select all

:040000050800178157

Its an address in the flash memory, but what would it be for? It doesnt look like my application start address, which is 0X08000000 its quite some way in.

Where does this address get loaded to since it isnt data??

EDIT: The above line changes when i change the program itself and recompile. I assume that the compiler is changing the application start address as it needs to. These entries "should" already be in the vector table, so i can ignore this line.

[Steve]

I don't know if this helps or not. This is from http://www.keil.com/support/docs/1584/# ... nt%20data.

Start Linear Address Records (MDK-ARM only)

Start linear address records specify the start address of the application. These records contain the full linear 32 bit address. The start linear address record always has four data bytes and appears as follows:

:04000005000000CD2A

where:

04 is the number of data bytes in the record.
0000 is the address field. For the start linear address record, this field is always 0000.
05 is the record type 05 (a start linear address record).
000000CD is the 4 byte linear start address of the application.
2A is the checksum of the record and is calculated as 01h + NOT(04h + 00h + 00h + 05h + 00h + 00h + 00h + CDh).

The Start Linear Address specifies the address of the __main (pre-main) function but not the address of the startup code which usually calls __main after calling SystemInit(). An odd linear start address specifies that __main is compiled for the Thumb instruction set.

The Start Linear Address Record can appear anywhere in hex file. In most cases this record can be ignored because it does not contain information which is needed to program flash memory.