Forums

Hex-Files - Record length

Started by Thomas Baier November 15, 2004
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
On Tue, 16 Nov 2004 00:34:59 +0100, Thomas Baier <thomas@tho-bai.de>
wrote in comp.arch.embedded:

> 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
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 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 Klein wrote:

> On Tue, 16 Nov 2004 00:34:59 +0100, Thomas Baier <thomas@tho-bai.de> > wrote in comp.arch.embedded: > >> 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 > > 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 >
Thomas Baier wrote:
> 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
"Thomas Baier" <thomas@tho-bai.de> wrote in message
news:4199d05e$0$28983$9b4e6d93@newsread4.arcor-online.net...
> 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 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.
> 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?
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. ;-)
In article <FBlmd.33429$Zr3.2101@fe1.texas.rr.com>, spam@anywhere.com 
says...
> > "Thomas Baier" <thomas@tho-bai.de> wrote in message > news:4199d05e$0$28983$9b4e6d93@newsread4.arcor-online.net... > > 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 > > 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. > > > 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? >
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.
> 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. ;-) > >
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 <thomas@tho-bai.de>
wrote in comp.arch.embedded:

> 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
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
On 2004-11-17, Jack Klein <jackklein@spamcop.net> wrote:

> Remember that writing a (byte, word, whatever width the flash > is) value of all 1 bits is a no-op to flash.
That's pretty much true.
> 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.
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.
> 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 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?