The Mega32 bootloader project
During the development of the Mega169 (Butterfly) webserver, the idea of having a
http:// bootloader came up and began to grow. After several tries with compilers
on the Mega169, we realized that the 2k of boot flash space were to little for the
intended functionality and that a compiler was not giving tight enough code. The
current implementation is in the order of 3k. We'll come back on that later.
The requirements for the http:// bootloader
I first wrote a proxy to connect the serial port with a http server socket.
The proxy was considered stupid, just a message passthrough, independent of the
attached functionality. The proxy would get the requests from a browser and
route it to the serial port and back. This meant the http:// bootloader would
have to understand the http requests and answer them appropriately. The bootloader thus
The guys from AjaxUp wrote a better proxy with a
platform independent user interface written in Java, where the user can drag n'drop
the firmware to be uploaded. They call it middleware, a phantastic piece of work.
- processes the http requests and answers appropriately.
- provides a default page which enables the uploading of firmwware
- is able to programm the application flash space of the controller
- is able to programm the EEPROM space
- provides basic code protection by a CRC
- provides basic IP protection by a simple encryption
- provides basic user authentication by a pin code
- sends just ASCII over the line to stay compatible, no binary
- a generous timeout on incoming messages wouldn't leave the
bootloader in a forgotten state
Some details of the http:// bootloader
Some experience with the Mega169 showed that a continous baudrate of 9600 bauds can
be sustained without any buffering. This was because one word took a bit less than
4ms to write (when the device is new), about the time it took to transmit 4 byte in
HexASCII at 9600 baud. For enhanced versatibilty I added some buffering. The current
implementation is written without interrupts.
The Protocol ist ASCII and as close to http as possible. The following commands and
replys are implemented:
The boot page is requested by the following commands :
The commands are terminated by CR LF CR LF or in hex 0x13 0x10 0x13 0x10. The reply
is the boot page and looks like :
ATMega32Eval Firmware Upload Page
There are 2 entry points into the bootloader. The first is the reset vector.
From this entry, the bootloader checks whether the application is valid and if
so jumps to it. The sercond entry is a is jumped to by the application. Then
the cheeck for a valid application is omitted and if nothing happens for a certain
time, the boot section is left after a ttimeout. During the bootloader being active,
it responds to communication to it.
The replay is terminates by a Zero, 0x00. We thus omit the usually transmitted
HTTP/1.0 200 ok Content-Length=..... At the current point, the
middleware does that for us. If necessary, it could be changed.
Another command that is accepted, it the upload.
Since the Content-Length is there, there is no terminal character, nor sequence.
The [Data] part is filled as :
Outlook on features to be implemented in the near future
- Systems would profit from recognizing devices, thus we want the device to
have a unique identification number in them. The bootloader would provide
- Users should be able to give the device a name. Since this name should be
checkable at firmware upload, the bootloader should provide this string.
- Developers do not need the security stuff at development time, but wish
faster uploads, this is doable.
- Certain application may want a better protected IP, a better authentication,
we'll look into that, knowing that a Diffie Hellman for key exchange
and AES for block transfers are beyond reasonability for a bootloader.
- The bootloader should read out and provide the version of the loaded
application software, a matter of definition where what is stored.
More is coming soon ...
A product on this is planned, but needs a few more touches.
Mega32 web server
embedded AVR page
last updated 27.Feb.08 or perhaps later
Copyright (99,2008) Ing.Büro R.Tschaggelar