Constants at a specific adress?

[tkjmail2]

Posted on April 03, 2010 at 18:36

Constants at a specific adress?

[Tesla DeLorean]

Posted on May 17, 2011 at 13:46

Both Intel Hex and Motorola S-Record have addresses and checksums for each line. I wouldn't call them packed as the hex files are typically about 2.5x bigger than a binary format describing the same data.

Each line typically describes 16 bytes, but the formats can often support more, it really depends on the tools, the linker creating them and the loader on the flasher or on the micro itself. Intel Hex files have lines starting with a colon, and can describe up to 64KB of address space, additional hex records can specify segments to expand the address range. Motorola S-Records, unsurprisingly have lines starting with 'S', different types of records us 16, 24 and 32-bit addresses. As long as your constant doesn't cross a hex line boundary you should be able to adjust a single line by changing the bytes of interest and recomputing the checksum. Beyond the trivial cases it is often easier to code something to read in the whole hex file, converting to binary, finding and adjusting the constants, and then re-export the hex file. If you have a string in the firmware, for example ''*********'' you should be able to locate this in the firmware by searching the text for 2A2A2A2A. For things like a serial number you could use some magic constant like char Serial[] = ''SeRiAlNuMbEr''; or frankly any pattern that would not normally occur in the compiled code. -Clive

[picguy2]

Posted on May 17, 2011 at 13:46

Go into your interrupt vector and add enough 0xFFFFFFFF words at its end for whatever you need to patch.  You should be able to know the address of these words without looking.  But look if you must.  Use a public symbol for your code to find these words.

[Andrew Neil]

Posted on May 17, 2011 at 13:46

''Each line typically describes 16 bytes, but the formats can often support more''

The Intel Hex format itself imposes no limit whatsoever on the line length. It is, however, a common fault in poorly-written tools to assume a certain fixed line length, or a limit to the line length.

[Andrew Neil]

Posted on May 17, 2011 at 13:46

Take a look at SRecord - a set of open-source tools to  manipulate EPROM load files:

http://srecord.sourceforge.net/

Don't be put off by the name: it's not just for Motorola S-Records; it also covers many other formats - including Intel Hex.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:46

''The Intel Hex format itself imposes no limit whatsoever on the line length.''

Things will go decidedly pear shaped if you try to express more than 255 hex bytes in a single line. So it is self limiting, or implied.''It is, however, a common fault in poorly-written tools to assume a certain fixed line length, or a limit to the line length.'' Generally a result of them being coded to reflect a specific example hex file, or two, to hand. There have been a number of broken linkers over the years, but most often the loader implementation have their own limits (based on implementation speed, size, efficacy, and efficiency), and PROM programmers with their own issues. A specific area of grief is typically the handling of segmentation (64KB), where the original Intel Hex implementation dates back to 8-bit micros, with the segmentation more of an after thought. The other issue with long lines is the effectiveness of the checksum algorithm used. -Clive

[Andrew Neil]

Posted on May 17, 2011 at 13:46

''Things will go decidedly pear shaped if you try to express more than 255 hex bytes in a single line.''

Yes, that's true - since the 'length' field is 2 hex digits Another common flaw is to require that records be in address order...

[darcy23]

Posted on May 17, 2011 at 13:46

Could you describe the application a little bit more?  Is the programming being done in a factory or is this file being sent to the customer to program etc...  If it's done in the factory then maybe you could make it a two stage process.  Is it a number that changes per update, or something that stays with that device permanently...  etc   Thanks

[tkjmail2]

Posted on May 17, 2011 at 13:46

Dear everybody.

I'm suprised to see so many posts in this post, as I've been away.

As Clive recommends, I should try making a constant variable array, and then try and search after that in the HEX file. That's just what I've done, and it couldn't find anything.

The code used to create the array is this:

const u8 Serial[8] = {0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC, 0xDE, 0xFF};

But I'm not able to find this in the HEX file!

It should be used for a Serial number, which is chosen when it is programmed. So it's not an update number which increases, like you ask about Darcy.

I hope this clears some things, and maybe you know why I can't find it in the HEX file?

Best Regards

Thomas Jespersen

[tkjmail2]

Posted on May 17, 2011 at 13:46

This is just a removed double post!