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?

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.

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?

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

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.

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.

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.

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