STM32F0 CAN Bootloader, HEX file interpretation

[danielblesener9]

Posted on July 19, 2017 at 21:55

I am developing a GUI to transfer code via CAN as a bootloader. 

Attached is an example of a hex file produced using RIDE7. The .xlsx attached is just the hex file split in a readable order, splitting the memory address (shown as decimal), data length (in bytes), record type, and data. 

There are 92KB of pages I am transmitting with the bootloader. Starting at memory address 0x08008000 and ending 92 pages later, with 1024 bytes per page, so with an ending address of 0x0801F000.

Looking at line 18 of the hex file or 19 of the xlsx, why is the jumps in memory only 12 bytes? The firmware is expecting my GUI to send data in 1024 chucks, the 12 throws it off so that the first 64 columns (1024 bytes / 16 bytes per line) is not even with 64? 

Also, why is the data 0 for line 18 & 20?

I expected to simply check the memory address as I sent data and fill any unfilled pages with 0xFF. 

I might not be understand hex files properly! Or the STM32. Any thoughts and advise will be appreciated. 

Thanks for your support, please let me know if anything is not clear. 

[Tesla DeLorean]

Posted on July 19, 2017 at 23:40

Yeah not seeing any attached .HEX file, and can't do much with .XLSX files here.

.HEX files in Intel or Motorola format can be sparse and out-of-order, basically the linker can emit records as it sees fit.

Here when processing .HEX, I load the entire file into a memory space I've prefilled with 0xFF, once I get to the completion record I can truncate the image based on the maximum address written. So a PC based loader would process the file, then send records across the wire.

.DFU or .ELF/AXF tend to be simpler in describing large memory region with linear binary data.

[danielblesener9]

Posted on July 20, 2017 at 00:57

Thanks for the quick replies Clive, I will look into that tomorrow but I don't have control over how the hex file is generated. Does my adding the hex file help or change your response at all?

[Tesla DeLorean]

Posted on July 19, 2017 at 23:47

The HEX to DFU tools was posted here.

https://community.st.com/0D50X00009XkeovSAB

 

There is a 'UM0391 User Manual' describing the DFU format, but doesn't appear to be hosted by ST anymore, or readily, Google the quoted text.

[Tesla DeLorean]

Posted on July 20, 2017 at 02:57

The .HEX file looks to be valid. Line 18 is a short line with 12 bytes, the lines from then on until the segment change are at addresses offset by 12, ie 0x0800810C, 0x0800811C, etc

That's not as clean as you might like, but not a generation failure.

For CAN where you have an 8-byte payload, definitely non-optimal. The programming app should load and rationalize the data if that is what is required.

Not sure of what the complaint is about line 20, it is a 00 data record, 05 is an entry point record, 01 is an end record, and 04 is a segment record.

[Tesla DeLorean]

Posted on July 20, 2017 at 04:26

Attached a rationalized version of the .HEX, outputting 32 bytes per line.

________________ Attachments : out.hex.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyTK&d=%2Fa%2F0X0000000b9V%2FUgQB50CPsoqQoToN75to2doOd7jXZ.5tP4Q2lsydxlU&asPdf=false

[danielblesener9]

Posted on July 23, 2017 at 19:35

Clive, I am not sure how you generated that or why 32 byte lines are necessary. The memory offset makes sense. I agree it is not very clean but also agree it is possible and should be accounted for in the GUI parsing algorithm. 

I think I can organize the 92 pages of 1024 in code without issue if I understand why it looks like all the data is not showing for this file. The excel file I attached shows the 'Jumps In Memory' column. This is simply subtracting the address from each line in the hex file. I think that all of these memory jumps should add up to 1024*92 = 94208 bytes. 

Through out the file I made the lines with line record types not = data 0. So the sum of the column (exclude the last few lines at the end of the file, the last 3 are not 0 and are not data records - it will be obvious) should be 94208. I have tried this many, many times and I ALWAYS get 94156 bytes. Can you explain this?

Or explain how you generated the correct file? 

Thanks for all of your help.

[danielblesener9]

Posted on July 23, 2017 at 23:19

I realized a simpler way to look at the total memory span is to take the last data memory address in the hex file and subtract the last. This is 134344652-134250496 = 94156. I would think this should be 1024*92=94208.

Thanks!

[Tesla DeLorean]

Posted on July 23, 2017 at 23:34

The .HEX file has voids in it, either due to the lack of data behind those areas, or related to how the linker script or scatter file is managing load regions.

I output 32-byte lines because it is more efficient to do so, and a valid format variation. Tools output a wide variety of forms, they can contain voids, be non-linear/contiguous, and contain records of variable size.

..

:04B8DD000000000067

:10EFBC000139383736353433323100000000000067:08EFCC00000000000002030038:040000050800814529:00000001FF

The last two records are non-data, the 05 describes the entry point (Reset_Handler) and 01 is the terminal record.

[danielblesener9]

Posted on July 24, 2017 at 01:35

Right, the terminal record and entry point makes sense. I think what you mean by void is jumps in memory with no data shown. I just fill these with 0xFF. But what should be shown is an ending memory address that is 1042*92 in difference from the starting, but that is not the case. I have no way of knowing where to add the extra 0xFF bytes. At the beginning? At the end?