Hex-Files - Record length

On Tue, 16 Nov 2004 00:34:59 +0100, Thomas Baier wrote in comp.arch.embedded:

The problem is that you haven't defined the format of your "hex files". There are several widely used formats, mainly Intel Hex, Tectronix Hex, and Motorola S-Record. But there are a lot of other applications that don't use one of these standard formats and just "make up" one of their own.

If you use one of the standard formats above, no you don't need to pad your records with anything. Each record specifies a start address and a length, and then includes exactly as many data bytes as the length says, no more and no less.

If you are making your own loader you might want to use one of the standard formats, they are well defined and well supported. Even if the original microcontroller system did not.

You can find a full description of Intel Hex format here:

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

Thanks for your answer. I'm using Intel-Hex and my problem is that I don't see the point padding my records with 0xFF, but when I use the given bootloader that comes with the microcontroller I have to, because it expects always 32 Byte of data and ignors the real length of the record. So why could that be? Is it maybe just that it is easier to programm a bootloader that always wants a fixed size (32 Byte) of data and the 0xFF does not have any effect to the microcontroller?

Greetings

Thomas

Jack Kle> On Tue, 16 Nov 2004 00:34:59 +0100, Thomas Baier

At first glance it looks simply slack - but it might be the page size of the FLASH that determines the 32 byte blocks. FLASH physically erases and writes many bytes at a time. If the loader allowed scattered hex, then you would need more complex buffering schemes, and suffer more wear on the flash.

-jg

don't

record. So

It's probably not ignoring the length field of the record, or it would be writing 0xFF to the flash memory. It's just that the guy that wrote the bootloader likely thought it would be easier to just read fixed length chunks from the hex file data, rather than using the length field to determine how much to read. He most probably is using the length field to determine how much data to write to the flash.

IIRC, there should be a utility available that you can use that will "re-pack" your hex file into fixed length records.

0xFF

Yes on the first question, but it probably doesn't much matter what you pad your lines with. Try using something other than 0xFF as padding for grins. ;-)

That could well be the case. Many (all?) types of flash contain 0xFF bytes in their erased condition. It may be that padding with 0xFF causes no additional wear and tear on the flash because erasing bytes that are already erased is not a problem.

If your compiler and/or linker is efficient, there shouldn't be too many records that need padding.

Mark Borgerson

On Tue, 16 Nov 2004 10:58:55 +0100, Thomas Baier wrote in comp.arch.embedded:

Remember that writing a (byte, word, whatever width the flash is) value of all 1 bits is a no-op to flash. An erased flash is all 1 bits, and when programming it by writing to it, all you can do is turn some or all of the 1 bits to 0 bits. Writing 0xff to most flash (or

0xffff to 16 bit flash) is generally the command to take it out of programming/erase mode and back into ordinary read mode.

So the boot loader you are talking about can have less code to deal with variable record size if it always receives records with exactly

32 bytes. It can even write the extra 0xff bytes after the real data to the flash, and it will have no effect at all on those flash locations, regardless of what is already in them.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

That's pretty much true.

No it isn't. [How can it be a noop _and_ an end-programming command?]

I've written flash burning routines for a dozen different types of flash, and I've never seen a flash where burning all 1's to an erased location took it out of program mode. If that were true, any hex file that contained a ff (or ffff) value in the middle of the file would fail to program, since the part would drop out of program mode unexpectedly.

I've never seen that guaranteed. Many flash parts prohibit trying to write a 1 to a location that already contains a 0. I've done it by accident, and it doesn't usually hurt anything. But, unless the part's spec states that it's allowed, you shouldn't do it.

--
Grant Edwards                   grante             Yow!  Where do your SOCKS
                                  at               go when you lose them in
                               visi.com            th' WASHER?