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

[Ole Reinhardt]

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