avr-gcc-list
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]