AVR Freaks

You are always writing a page no matter what. Whatever the temp page holds, will be written. If all the bits in the temp page are 1 except for 1 bit which is 0, then even though the whole page is written, only 1 bit of flash will be changed (assuming its not already 0). That's the way flash works, and can be used to your advantage.

I require an erase before programming, so in my case I don't have to erase/write for each record.

Unless you want to recompile avr-objdump (you probably don't), you either figure out srec (it may be able to), or simply write a script in your language of choice. I did the latter, only to test my theory and to implement encryption. Its not that hard, but is not used daily because I only deal with 16k or less. If I was using a large avr, it would probably be worth the effort if using the bootloader frequently.

You can use the output of the bootloader as flow control, as Stu does, but that means the PC side has to be a little smarter than 'dumb'. I have sort of the same setup, where I get a command prompt after each record. The command prompt character determines what I'm able to do, along with an error character at the end of a bad record or usart error. I have tried using these with a 'smarter' terminal ('flow control'), and it does speed things up a little since the usual line delay value is for the worst case possible. In my case, I'm dealing with relatively small avr's, and is not worth the effort (to me). One thing you can do with a 'smarter' terminal, is check that the characters echoed back from the bootloader match the ones sent, which would be in addition to the record checksum. Although possible to get a good checksum with bad data, it would be harder to also have echoed characters screw up exactly as it did going into the bootloader.

I also do not like automatically retransmitting failed records (like xmodem for example), since I want to know about ANY failures. I never get transmission failures, so if I happen to get one, I want to know about it (somethings wrong, or is failing). Transmitting over a phone line is a different story of course, and if using the phone line to do updates, I would be in favor of something like xmodem.

That's a great idea.

You can change a single line of a standard MFile-generated makefile to switch the output format from Intel Hex to raw binary. Note that the file extension doesn't change by default, but the file's contents will change format.

(If you have planned for any "holes" in your flash file, though, you'd be well advised to double check first to see how avr-objdump deals with those holes - does it fill them with 1's, or fill them with 0's, or silently omit them entirely? The first possibility would be ideal, the second possibility might potentially wear out your Flash more quickly depending on how intelligent your bootloader is at detecting unchanged pages, and the third possibility would most likely lead to incorrect functionality. If you needed to guarantee the way holes were filled, then you'd be better off leaving avr-objdump's output in Intel Hex format, and converting to raw binary using SRecord, which gives you the option of specifying exactly what default value to assign to holes.)

When coupled with the Xmodem protocol for error detection, you should be perfectly safe to use the raw binary format to optimize transfer speeds.

Yes, any reputable XMODEM file transfer program will automatically insert the headers and checksums/CRCs (depending on receiver capability) for you.

It would not be an instruction to the compiler, but rather an instruction to the avr-objcopy utility. This stage is run after the compiling and linking stages have both already finished. I've never actually used kontrollerlab, so I don't know if it would be possible to customize it for this purpose.

It might be easier to use SRecord to post-process the hex file into a raw binary file. SRecord is available as a package in several Linux distributions. I won't pollute this thread by getting into details unless you ask.

when avr-objdump outputs a binary image (with -O binary), there is no address info except for the byte location within the file, so any 'holes' have to be filled with something (its 0 in this case) and the binary ends at the last byte produced.

(I use binary output when creating my own 'big' hex records, or encrypted records, since it means no decoding of a hex record is needed, only encoding)

I could be wrong, but I wouldn't worry about wearing out flash, unless your name is Bob, and you live in Florida, use a Mega32, and flash at least 10 times a day on the same Mega32 for about 3 years.

Actually, even a 'smart' bootloader will need to erase the first page on a mega128 probably 99 times out of 100, since the copy data routine will be using a different data load address any time the size of the app code changes. Since a bit needs changing, an erase is needed. A 'super-smart' bootloader that can also determine when only bits need to go from 1->0, would probably help only a little. Since the first page(s) will probably wear out first, it will not matter that the other pages have some life left in them. That's my theory. (Eeprom is a different story, and I think IS worth the little effort needed to reduce the number of erases).