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
- 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
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.
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
Coming a bit later....
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
this number
- 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
projects page
embedded AVR page
home
last updated 27.Feb.08 or perhaps later
Copyright (99,2008) Ing.Büro R.Tschaggelar