3
$\begingroup$

I was given the compiled program from an automotive ECU by my colleagues in HEX-format, as well as the corresponding A2L-file. For my project I need to read the applied parameters from that HEX-file. I want to do this automatically, via a MATLAB function, as the parameters are used as inputs in a Simulink model.

Now as an example the HEX-file looks like this:

[…]
:2001C00000000000000000000000000000000000000000000000000000000000000000001F
:2001E0000000000000000000000000000000000000000000000000000000000000000000FF
:2002000054710780809A0780809A0780809A07808C530680000011A0140011A000000000D4
:200220000000000000000000000000000000000000000000000000000000000000000000BE
:2002400000000000000000000000000000000000000000000000000000000000000000009E
:2002600000000000000000000000000000000000000000000000000000000000000000007E
[…]

(please note that it is just an exemplary excerpt)

The address for a certain parameter can be read from the A2L for example as ‘0xA0143B0B’. From the specification on the XCP-protocol I know that the address in the A2L is 40-bit long (32-bit address and 8-bit extension). As you can see the address I read is 64-bit. Now if I got it right in my exemplary address ‘A01’ is reserved, ‘4’ is the address extension and ‘3B0B’ is the actual 32-bit address.

Can anyone confirm this or correct me if I am mistaken?

Reading the data from the HEX-file in position ‘3B0B’ is incorrect. My colleagues exported the data for me in a text file to verify my results, and they clearly differ. Are the ‘:’ counted when the position is addressed?

Edit: I just found out that 'A01' defines the RAM-Segment the data is written in. But how can I find this Segment within the HEX-File?

$\endgroup$
1
  • $\begingroup$ I forgot to mention: the data is all in Intel notation (little endian), for the address I do not know. $\endgroup$ – J.M. Mar 1 '17 at 9:57
1
$\begingroup$

This is Intel hex format, not your raw hex dump - so no, position in the file won't be of much help. These are records, with length, address, record type, data and checksum.

enter image description here

Of course, as result of that overhead, the byte at position 3B0B in your hex file will be completely different. You need to decode the Intel Hex file into raw binary (apply offsets/addresses, strip headers and so on - the data in .hex is not guaranteed to represent continuous segment of memory) and only there your 3B0B will point at the right location.

$\endgroup$
5
  • $\begingroup$ Thanks for the answer, that really helped. Now I started writing a MATLAB script to convert the data to a binary file. How do I convert the data set (Cyan in your example Picture) $\endgroup$ – J.M. Mar 2 '17 at 8:11
  • $\begingroup$ @J.M.: following the format specs, no easy way or shortcuts around it (unless you find a library that can do it). $\endgroup$ – SF. Mar 2 '17 at 8:39
  • $\begingroup$ Okay, now I wrote a Script and end up with a binary with approx. 3.6 million bits. How do I use the addresses I read from the A2L now? Do I use for example '0x3B0B'? Do you know what the reserved '4' is used for? $\endgroup$ – J.M. Mar 2 '17 at 13:55
  • $\begingroup$ @J.M.: uh, 3.6 million bits? I hope bundled into bytes, and not separate '0' and '1' characters? Well, I don't know the XCP-protocol but now that you unpacked the Intel Hex to binary, you process the binary according to XCP. Also: 0xA0143B0B is actually 32 bits, not 64 - each hex character represents 4 bits. I'm afraid I can't help you with that though; never did anything with XCP and I have no clue how to decode it. $\endgroup$ – SF. Mar 2 '17 at 14:17
  • $\begingroup$ yep converted of course. Okay, I'll have to look into the XCP Protcol in this case.. It cannot be that easy since the binary does not have as many Bytes as stated by the address. And you are right about the address - it is actually 32 bits :-/ $\endgroup$ – J.M. Mar 2 '17 at 14:39
0
$\begingroup$

Intel HEX format is well documented out there. Basically, it contains a bunch of bytes at specific addresses.

Surely there are also many utilities out there that read HEX files and do various things with the information in them. For example, here is the output of my HEX_DUMP utility run on the snippet you provided:

000001C0-000001DF (32): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00
000001E0-000001FF (32): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00
00000200-0000021F (32): 54 71 07 80 80 9A 07 80 80 9A 07 80 80 9A 07 80 8C 53 06
  80 00 00 11 A0 14 00 11 A0 00 00 00 00
00000220-0000023F (32): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00
00000240-0000025F (32): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00
00000260-0000027F (32): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00

This output is showing you the address range resulting from each line, the number of data bytes on that line, then the actual data bytes in HEX.

What that data means and what you do with it is, of course, up to you.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.