[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] New list member, and bootloader question
From: |
Geoffrey Wossum |
Subject: |
Re: [avr-gcc-list] New list member, and bootloader question |
Date: |
Sat, 27 Mar 2004 19:31:54 -0600 |
User-agent: |
KMail/1.5 |
> My question is how do I make the compiler generate the stack and register
> setup at the bootloader location instead of at 0x0000 and how do I make the
> data (in this case an ID string I send out the serial port) get located
> there instead of in program space? I currently just used inline assembly
> to set the stack up, but I can't quite figure out how to make the linker
> stick the data in the bootloader area.
Search the avr-gcc or avr-libc list archives for xnutboot, a simple bootloader
which receives XMODEM over a serial port to flash the part. It works, it's
small and easy to understand and easy to extend. It's also under a BSD
license so you can extend it and use it in a commercial product with no
problem. I checked with the author to be sure before I used it in my
products.
I extended xnutboot to do a couple of extra tricks:
1) Check the validity of the application image in the ATmega. I have a script
which appends the CRC-16 followed by the length of the firmware image to the
end of the application image. When the bootloader starts, it begins
calculating the CRC-16 of the image. Whenever the check remainder comes up,
it checks the next two bytes to see if they correspond to the length of the
image which has been checked so far. If so, then there is a good firmware
image. If not, keep scanning. If the top of the application area is
reached, then there is no application image or it is corrupt, so begin trying
to receive a new firmware image. On a 3.6864 MHz ATmega128, it takes about 1
second to scan the entire application image area this way. Of course, if
there is good firmware, it takes less time since you can stop scanning
earlier.
2) Check the internal E2 for a "download firmware signature". The main
application will write this signature to the E2 and vector to the bootloader.
When the bootloader sees this signature, it begins trying to download new
firmware, even if the application image is good. The bootloader overwrites
these signature bytes immediately to prevent odd failures.
And of course, where appropriate, I setup I/O and display status information
on the device. On my devices with alphanumeric LCDs, I even show little
progress bars as the firmware image is being checked or downloaded, and
display messages if the image is corrupt.
If you really want to see an advanced bootloader, the same guy who wrote
xnutboot wrote a bootloader called enutboot, which is available at
www.ethernut.de. It downloads a firmware image using TFTP over Ethernet.
---
Geoffrey Wossum
Software Engineer
Long Range Systems - http://www.pager.net
_______________________________________________
avr-gcc-list mailing list
address@hidden
http://www.avr1.org/mailman/listinfo/avr-gcc-list