Hex-Files - Record length

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi there,

I'v got the following problem: I've got a C164CI microcontroller (Infineon)
and I've written a prog to send Hex-Files to it. When I work with the
integrated OS of the microcontroller I always have to add '0xFF's to every
record that has less than 32 byte. Now I'd like to write my own bootloader
for the microcontroller and my question is:

Do I always have to fill my hex records with 0xFF and what does that cause
at the microcontroller?


In my current version of my bootloader I just read in the adress and length
and then read $lentgh bytes and write them to the adress. So if I would
extend my records with 0xFF my bootloader would read read FFFF as the
adress then the next FF as the length and then it would wait for FF (255)
more bytes and writes them to memory.
I think this doesn't make sense, does it?



Thanks for your help

Thomas

Re: Hex-Files - Record length
wrote in comp.arch.embedded:

Quoted text here. Click to load it

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:

http://jk-technology.com/x86/intelhex.txt

--
Jack Klein
Home: http://JK-Technology.Com
We've slightly trimmed the long signature. Click to see the full one.
Re: Hex-Files - Record length
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 Klein wrote:

Quoted text here. Click to load it


Re: Hex-Files - Record length
Quoted text here. Click to load it

  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


Re: Hex-Files - Record length

Quoted text here. Click to load it
don't
record. So

It's probably not ignoring the length field of the record, or it would
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.

Quoted text here. Click to load it
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.  ;-)


Re: Hex-Files - Record length
says...
Quoted text here. Click to load it


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.


Quoted text here. Click to load it

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

Mark Borgerson



Re: Hex-Files - Record length
wrote in comp.arch.embedded:

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Hex-Files - Record length

Quoted text here. Click to load it

That's pretty much true.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline