[En-Nut-Discussion] Fwd: RE: Reprogramming

[macsmaker at aol.com]

You are correct, I have this backwards. The boot loader should be loaded into upper flash, and my application into lower flash. The jump to the bootloader should be somehwere into upper memory, not to 0x0000.



-----Original Message-----
From: Ole Reinhardt <ole.reinhardt at embedded-it.de>
To: Ethernut User Chat (English) <en-nut-discussion at egnite.de>
Sent: Tue, Jan 26, 2010 8:28 am
Subject: Re: [En-Nut-Discussion] Fwd: RE: Reprogramming




Hi Pete, 
 
Sorry, I still don't understand why you won't use the AVR bootloader 
section (at the top of the flash) to store your bootloader code.  
 
I would just place eboot at this section and programm the fuse bits 
accordingly. So everytime your device is started the CPU will start at 
the bootloader code.  
 
You have to modify the bootloader in a way that it normaly just jumps 
into your application at 0x0000. If your application wants to update it 
could set a flag in the eeprom area, which will be resetted next time 
your application runs successfully. Next jump into the bootloader 
section and download the new code.  
 
If flashing fails for whatever reason the "good" flag is not resetted 
and the bootloader will try to obtain a new application binary next time 
the device is started.  
 
> 1. Build a bootloader. Looks like I have two to choose from: eboot in the  
Ethernut 1.3 examples or 
>     avr109. I think the Ethernut example has at least enough of a protocol  
stack to communicate with 
>     the TFTP server. I have not research the avr109 yet. 
>     The bootloader needs to be loaded at hex 0000. 
 
The notmal AVR bootloader section is located at the top of the flash. 
0x0000 is always your application section. 
 
> 2. Figure out how big the bootloader is in bytes. 
> 3. Figure out the fuse settomgs to divide the flash into two sections, the  
smaller of which is *just* large 
>     large enough to hold the bootloader. 
 
Yes. On AtMega128 you can decide between 2K, 4K, 8K of code. 
 
> 4. Add a command to my app to force a jump to the bootloader code (at hex  
address 0000?) 
 
No, to the bootloader section at the top of your code. 
 
> 5. Compile my app, and make sure the linker puts the proper starting address  
in. 
 
This have to be done for your bootloader, not your application as your 
application will be located at 0x0000 
 
> 6. Use avrdude and the STK500 to set the fuses and then load each hex file. 
> 7. It's my understanding eboot will accept a binary from the host when the  
software is to be updated.  
>     The server will issue some sort of "update software" command (using an  
HTTP message) which 
>     will cause my app to jump to 0x0000. Not sure what handshaking needs to  
take place to start the  
>     file transfer, or what to do for disaster recovery. 
 
Similar. Yes. Again, jump to your bootloader not to 0x0000. As your 
bootloader can't overwrite itself in the protected bootloader section of 
the flash it is always available and will be started always first after 
power up. You have to check if the last update was successful and decide 
if you want to run your application or load a new binary. Quite simple. 
 
Btw: instead of jumping to your bootloader code you could better 
implement a full reset using the watchdog reset. 
 
Regards, 
 
Ole Reinhardt 
 
--  
 
Thermotemp GmbH, Embedded-IT 
 
Embedded Hard-/ Software and Open Source Development,  
Integration and Consulting 
 
Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen -  
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 
 
Hauptsitz - Hademarscher Weg 7 - 13503 Berlin 
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt 
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280  
 
_______________________________________________ 
http://lists.egnite.de/mailman/listinfo/en-nut-discussion