[En-Nut-Discussion] Fwd: RE: Reprogramming
macsmaker at aol.com
macsmaker at aol.com
Mon Jan 25 21:00:31 CET 2010
I (think) I know what I want to do, just not sure the best (canonical) method of getting there.
What I *think* I need is (this is for an Ethernut 1.3 with an Atmel128 running Nut/OS:
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.
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.
4. Add a command to my app to force a jump to the bootloader code (at hex address 0000?)
5. Compile my app, and make sure the linker puts the proper starting address in.
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.
Does this make sense to anyone who has done this? I'm kind of flying blind here and have a deadline to meet.
From: Thiago A. Corrêa <thiago.correa at gmail.com>
To: Allister G. Mannion <allister at nowatt.com>; Ethernut User Chat (English) <en-nut-discussion at egnite.de>
Sent: Mon, Jan 25, 2010 10:07 am
Subject: Re: [En-Nut-Discussion] Fwd: RE: Reprogramming
On Mon, Jan 25, 2010 at 1:32 PM, Allister G. Mannion
<Allister at amannion.com> wrote:
> Hi Ole,
> I have a similar requirement (might be the same as Peter's) where I want
> to keep the eboot code as part of my 'firmware'. At the moment I load
> (flash) it as a standalone, then flash my code (without the erase cycle)
> which always gets executed first. The reason I want the 'eboot' code
> there is so I can jump to it to tftp a new version of my firmware.
>From what I understand, you can already just jump to eboot, even if
they are not one single binary.
But if I'm missing the point, then the AVR32 DFU bootloader might be
of some inspiration to this I guess.
>From what I understand, they build it seperately, and then link with
the application where their assembly CRT does a .include
"boootloader.bin". This way, the entiere bootloader is placed in front
of the app. There is also a trampoline code (a jump) to the app area
when the bootloader is not supposed to run, so it starts the app and a
little link script trick defining an program_start symbol.
Might be worth taking a look.
Thiago A Correa
More information about the En-Nut-Discussion