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

[Allister Mannion]

Dear Peter,

This is the functionality I get with my not so encapsulated hack (don't
know if you saw my last email). 

Basically I load the eboot and Ole-delivered monitor on my Ethernut 1.3
platform. I then use the delivered monitor to flash the board with my
firmware (which thankfully through luck, rather than judgment doesn't
seem to overwrite the eboot code in the top of momory).

My firmware, like the delivered monitor program, has an option to jump
to the eboot code so I can flash it with my latest firmware. My firmware
is is still being developed and I didn't want to have to use the SPI
programmer or serial line. My firmware is basically a webserver. One of
the screen gives me the option to jump to the eboot code.

So as long as my firmware runs (I don't introduce a fetal bug!) I'm able
to develop it with the SPI programmer or serial console. This is what
was most important to me. I just wish I could include the eboot code in
my firmware instead of having to flash it in with a separate step. 

Of course when my firmware fails to start I have to get the SPI
programmer and PC with a serial port to once again re-flash the eboot
code and Ole-developed monitor. I can then hit the 'G' on Ole's monitor
to restore my last good firmware and I'm once again free of the SPI
programmer. 

I hope that when I finish my firmware and hardware I'll be able to have
something like this in the field. In production I want to be able to
re-flash our product without an SPI connector (i.e. via the enet).

Allister

On Mon, 2010-01-25 at 15:00 -0500, macsmaker at aol.com wrote:

> 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.
>  
> Pete Allison
> 
>  
> 
> 
> -----Original Message-----
> 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
> 
> 
> 
> 
> Hi, 
>  
> 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. 
>  
> Kind Regards, 
>     Thiago A Correa 
> _______________________________________________ 
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion 
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion



Allister Mannion
ΠΟωaττ - saving more than you think
+41 79 7591554
www.nowatt.com