--- In l..., "donhamilton2002" wrote:
>
> --- In l..., "mjames_doveridge" wrote:
> >
> >
> > One way - name the file after the version number, eg 'V7-03.IMG'. On startup, check any SD card for '*.IMG' and only load in such a file if the version number in the filename is later than the version of software already loaded.
>
> A problem that can be a killer is the user pulling out the SD card while it being used to read the new image.
>

Yes :(

I have used an extra serial flash chip to transfer the new image into the system, where the user can not fool with it.

That should be OK. I don't need any serial flash with my system because I have enough room in flash for two banks of main app. If both banks contain valid images, my loader overwrites the older of the two stored versions.

Rgds,
Martin

An Engineer's Guide to the LPC2100 Series

--- In l..., "mjames_doveridge" wrote:
> One way - name the file after the version number, eg 'V7-03.IMG'. On startup, check any SD card for '*.IMG' and only load in such a file if the version number in the filename is later than the version of software already loaded.

A problem that can be a killer is the user pulling out the SD card while it being used to read the new image.

I have used an extra serial flash chip to transfer the new image into the system, where the user can not fool with it.

You will want to verify the checksum of the SD card image before using it anyway.

So copying the new image to the serial flash can have its checksum verified before writing it to the internal flash.

If the power is lost or the user pulls out the SD card, the new image is always available.

Also, at powerup, you can check the flash image in the cpu and if the cpu flash gets corrupted, it can be reloaded without the SD card being available.

don

--- In l..., Sutton Mehaffey wrote:
>
> The secondary bootloader is a good idea. Thanks for that.
>
> One caveat. My SD card is multipurpose, so the user might have the SD
> card inserted on power on. The way I envision the user loading new
> firmware is to email the binary file to him, have him put the file in
> the proper UPDATES directory on the card and go to the proper menu
> item. The SD card is also used to save configurations, save reports,
> and upload audio files. So, I don't want to automatically look at the
> SD card on power up for a new image. I'll need some type of flag that
> indicates 'bad image' and 'good image'. When the uploading starts, set
> flag to 'bad image'. That way, if the upload doesn't succeed, the 'bad
> image' flag will automatically look for a new image. I think someone
> mentioned that. This may work.
>

One way - name the file after the version number, eg 'V7-03.IMG'. On startup, check any SD card for '*.IMG' and only load in such a file if the version number in the filename is later than the version of software already loaded.

Rgds,
Martin

I'm not quite understanding what you mean by upload image. Do you mean
transfer it to the SD card? Or, do you mean write image to flash?

In the case of the TNkernel bootloader, it puts in a CRC after writing
the image, so that the code image can be checked on boot before allowing
execution. If the CRC fails, which indicates a programming failure,
then it just stays in the bootloader. In your case this could copy
the image to flash again.

You should only rely on a signature in RAM to get you into the bootloader
initially. Once executing the bootloader, this signature is wiped out
regardless of the result. Otherwise, you can't deal with power cycles
well, since any state info carried by the signature would be lost.

Mike
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Sutton Mehaffey
> Sent: Saturday, August 01, 2009 9:14 PM
> To: l...
> Subject: Re: [lpc2000] Re: Writing your own Bootloader - tips needed
> Good idea also.
>
> In this case, if the user requests a firmware update, change the RAM
> signature to 'bad image', upload new image, change RAM signature to
> 'good image' and reset processor. If something happens during the
> upload, the RAM image will still be 'bad' and so the bootloader will
> always be invoked until a good firmware upload.
>
> However, if the file doesn't exist on the card for some
> reason, I could
> always change the RAM signature back to 'good image', and reset
> processor. Just voicing outloud for some adverse conditions.
>
> Sutton
>
> Michael Anton wrote:
> >
> >
> > > -----Original Message-----
> > > From: l...
> > > [mailto:l...
> > ]On Behalf
> > > Of Sutton Mehaffey
> > > Sent: Saturday, August 01, 2009 8:39 PM
> > > To: l...
> > > Subject: Re: [lpc2000] Re: Writing your own Bootloader -
> tips needed
> > >
> > >
> > > The secondary bootloader is a good idea. Thanks for that.
> > >
> > > One caveat. My SD card is multipurpose, so the user might
> > > have the SD
> > > card inserted on power on. The way I envision the user loading new
> > > firmware is to email the binary file to him, have him put
> the file in
> > > the proper UPDATES directory on the card and go to the proper menu
> > > item. The SD card is also used to save configurations,
> save reports,
> > > and upload audio files. So, I don't want to automatically
> > > look at the
> > > SD card on power up for a new image. I'll need some type of
> > > flag that
> > > indicates 'bad image' and 'good image'. When the uploading
> > > starts, set
> > > flag to 'bad image'. That way, if the upload doesn't
> > > succeed, the 'bad
> > > image' flag will automatically look for a new image. I
> think someone
> > > mentioned that. This may work.
> > >
> > > Sutton
> > >
> >
> > I would use a secondary bootloader that looks for a
> specific file on the
> > SD card. After the image has been successfully written to
> flash, delete
> > the file. The SD card can stay inserted all of the time.
> >
> > Take a look at TNkernal. There is a USB bootloader on the same site
> > that implements a secondary bootloader. If the main
> application wants
> > to get back into the bootloader, a specific signature is written to
> > RAM, and the processor is reset. The bootloader looks for this
> > signature, and then executes. In this manner, you would not always
> > have to look for the firmware file on boot, and you could look if
> > there is currently no firmware installed, or the main application
> > requested you to.
> >
> > Mike
> >
> > --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr. #100
> Kennesaw, GA 30144
> 800-207-6269, 770-514-7999, 770-514-1285 FAX
> s...@lookoutportablesecurity.com

Good idea also.

In this case, if the user requests a firmware update, change the RAM
signature to 'bad image', upload new image, change RAM signature to
'good image' and reset processor. If something happens during the
upload, the RAM image will still be 'bad' and so the bootloader will
always be invoked until a good firmware upload.

However, if the file doesn't exist on the card for some reason, I could
always change the RAM signature back to 'good image', and reset
processor. Just voicing outloud for some adverse conditions.

Sutton

Michael Anton wrote:
>
>
> > -----Original Message-----
> > From: l...
> > [mailto:l...
> ]On Behalf
> > Of Sutton Mehaffey
> > Sent: Saturday, August 01, 2009 8:39 PM
> > To: l...
> > Subject: Re: [lpc2000] Re: Writing your own Bootloader - tips needed
> >
> >
> > The secondary bootloader is a good idea. Thanks for that.
> >
> > One caveat. My SD card is multipurpose, so the user might
> > have the SD
> > card inserted on power on. The way I envision the user loading new
> > firmware is to email the binary file to him, have him put the file in
> > the proper UPDATES directory on the card and go to the proper menu
> > item. The SD card is also used to save configurations, save reports,
> > and upload audio files. So, I don't want to automatically
> > look at the
> > SD card on power up for a new image. I'll need some type of
> > flag that
> > indicates 'bad image' and 'good image'. When the uploading
> > starts, set
> > flag to 'bad image'. That way, if the upload doesn't
> > succeed, the 'bad
> > image' flag will automatically look for a new image. I think someone
> > mentioned that. This may work.
> >
> > Sutton
> > I would use a secondary bootloader that looks for a specific file on the
> SD card. After the image has been successfully written to flash, delete
> the file. The SD card can stay inserted all of the time.
>
> Take a look at TNkernal. There is a USB bootloader on the same site
> that implements a secondary bootloader. If the main application wants
> to get back into the bootloader, a specific signature is written to
> RAM, and the processor is reset. The bootloader looks for this
> signature, and then executes. In this manner, you would not always
> have to look for the firmware file on boot, and you could look if
> there is currently no firmware installed, or the main application
> requested you to.
>
> Mike

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
800-207-6269, 770-514-7999, 770-514-1285 FAX
s...@lookoutportablesecurity.com

> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of Sutton Mehaffey
> Sent: Saturday, August 01, 2009 8:39 PM
> To: l...
> Subject: Re: [lpc2000] Re: Writing your own Bootloader - tips needed
> The secondary bootloader is a good idea. Thanks for that.
>
> One caveat. My SD card is multipurpose, so the user might
> have the SD
> card inserted on power on. The way I envision the user loading new
> firmware is to email the binary file to him, have him put the file in
> the proper UPDATES directory on the card and go to the proper menu
> item. The SD card is also used to save configurations, save reports,
> and upload audio files. So, I don't want to automatically
> look at the
> SD card on power up for a new image. I'll need some type of
> flag that
> indicates 'bad image' and 'good image'. When the uploading
> starts, set
> flag to 'bad image'. That way, if the upload doesn't
> succeed, the 'bad
> image' flag will automatically look for a new image. I think someone
> mentioned that. This may work.
>
> Sutton
>

I would use a secondary bootloader that looks for a specific file on the
SD card. After the image has been successfully written to flash, delete
the file. The SD card can stay inserted all of the time.

Take a look at TNkernal. There is a USB bootloader on the same site
that implements a secondary bootloader. If the main application wants
to get back into the bootloader, a specific signature is written to
RAM, and the processor is reset. The bootloader looks for this
signature, and then executes. In this manner, you would not always
have to look for the firmware file on boot, and you could look if
there is currently no firmware installed, or the main application
requested you to.

Mike

The secondary bootloader is a good idea. Thanks for that.

One caveat. My SD card is multipurpose, so the user might have the SD
card inserted on power on. The way I envision the user loading new
firmware is to email the binary file to him, have him put the file in
the proper UPDATES directory on the card and go to the proper menu
item. The SD card is also used to save configurations, save reports,
and upload audio files. So, I don't want to automatically look at the
SD card on power up for a new image. I'll need some type of flag that
indicates 'bad image' and 'good image'. When the uploading starts, set
flag to 'bad image'. That way, if the upload doesn't succeed, the 'bad
image' flag will automatically look for a new image. I think someone
mentioned that. This may work.

Sutton
mjames_doveridge wrote:
>
>
> --- In l... ,
> "Sutton Mehaffey" wrote:
> >
> > I have never written my own bootloader, but I've just about finished
> writing all the code I need. I need to make sure I'm not missing
> anything. So, any tips from others who have done this is greatly
> appreciated.
> >
> > My application is for a 'dumb' user to be able to upload new
> firmware via SD card to a LPC2148 as new features to our product
> become available. I have an intermediary serial flash that I upload to
> prior to writing to CPU Flash. And, I gather that I must write to CPU
> RAM first, because there is only an IAP command to write from RAM to
> FLASH. So, I use the top 1K of RAM as my write buffer.
> >
> > If my upload crashes for some reason, my bootloader code has all the
> routines in it to completely restart from scratch the upload process.
> If this happens, does the user have to open up the system and ground
> P0.14 and press RESET in order to start the bootloader OR is there
> another way? I'd like to recover without the user getting inside the
> system to the circuit board, if possible.
> >
> > The upload from the SD to serial flash works perfect with a sanity
> check, then I write protect the flash. I haven't tested the code to
> actually start overwriting the FLASH, because I wanted to make sure I
> had everything covered.
> >
> > All of my bootloader routines are contained in 'bootload.c'. Using
> Keil's uVision, how do you put that entire file with all it's routines
> at 07FFFD000?
> >
> > Also, in case of a complete crash, is there a way to get back the
> old bootloader (V2.12) that is currently built into the LPC2148?
> >
> > Anything else I need to know? Probably....
> >
> > Thanks in advance.
> >
> > Sutton
> > IMHO, the 'secondary bootloader' approach, as suggested/used by Mike
> Deniset, is the best way to approach this. I use such a boot app to
> load the main app from an SD card, should one be fitted at startup and
> contains a valid image file. If the loaded/existing app. image is OK,
> the last action of the secondary bootloader is to jump to its start
> address. The main app. is self-supporting and runs up with no
> interaction with the bootloaders, setting its own stack, its own
> initializations, copy/map interrupt vectors to RAM, (important!), etc.
> etc.
>
> It works very well - all the customer has to do is shove in the card
> and power-cycle the box. I have no support routines in the secondary
> bootloader so the secondary bootloader should not have to change. If,
> for some reason, it does have to change, then a 'P0.14' reset would
> still force the primary bootloader to run, so allowing the secondary
> bootloader to be re-blown with FlashMagic, or whatever.
>
> Rgds,
> Martin

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
800-207-6269, 770-514-7999, 770-514-1285 FAX
s...@lookoutportablesecurity.com

--- In l..., "Sutton Mehaffey" wrote:
>
> I have never written my own bootloader, but I've just about finished writing all the code I need. I need to make sure I'm not missing anything. So, any tips from others who have done this is greatly appreciated.
>
> My application is for a 'dumb' user to be able to upload new firmware via SD card to a LPC2148 as new features to our product become available. I have an intermediary serial flash that I upload to prior to writing to CPU Flash. And, I gather that I must write to CPU RAM first, because there is only an IAP command to write from RAM to FLASH. So, I use the top 1K of RAM as my write buffer.
>
> If my upload crashes for some reason, my bootloader code has all the routines in it to completely restart from scratch the upload process. If this happens, does the user have to open up the system and ground P0.14 and press RESET in order to start the bootloader OR is there another way? I'd like to recover without the user getting inside the system to the circuit board, if possible.
>
> The upload from the SD to serial flash works perfect with a sanity check, then I write protect the flash. I haven't tested the code to actually start overwriting the FLASH, because I wanted to make sure I had everything covered.
>
> All of my bootloader routines are contained in 'bootload.c'. Using Keil's uVision, how do you put that entire file with all it's routines at 07FFFD000?
>
> Also, in case of a complete crash, is there a way to get back the old bootloader (V2.12) that is currently built into the LPC2148?
>
> Anything else I need to know? Probably....
>
> Thanks in advance.
>
> Sutton
>

IMHO, the 'secondary bootloader' approach, as suggested/used by Mike Deniset, is the best way to approach this. I use such a boot app to load the main app from an SD card, should one be fitted at startup and contains a valid image file. If the loaded/existing app. image is OK, the last action of the secondary bootloader is to jump to its start address. The main app. is self-supporting and runs up with no interaction with the bootloaders, setting its own stack, its own initializations, copy/map interrupt vectors to RAM, (important!), etc. etc.
It works very well - all the customer has to do is shove in the card and power-cycle the box. I have no support routines in the secondary bootloader so the secondary bootloader should not have to change. If, for some reason, it does have to change, then a 'P0.14' reset would still force the primary bootloader to run, so allowing the secondary bootloader to be re-blown with FlashMagic, or whatever.

Rgds,
Martin

--- In l..., "Sutton Mehaffey" wrote:

> If my upload crashes for some reason, my bootloader code has all the routines in it to completely restart from scratch the upload process. If this happens, does the user have to open up the system and ground P0.14 and press RESET in order to start the bootloader OR is there another way?

Your bootloader will have to start up at 000000 somehow I think. It could then have the micro go somewhere else for your bootloader I suppose, but I'd just leave it in low memory. It's probably easiest. My main program starts at 0x0001000 or 0x0002000. Holding P0.14 low during reset is for when ~you~ first load the part with your bootloader and possibly the main program. Besides, you wouldn't want your customer to have to learn say, Flash Magic, would you ? The built in bootloader doesn't know what to do with SD flash anyway. Your bootloader will have to handle that.

> Anything else I need to know? Probably....

Yes, probably. There is ~always~ something else to know !
This is a great site to get that knowledge though. Ya'all helped me a lot when I was first trying to do this. It takes some careful thought (and time) for sure.

boB
>
> Thanks in advance.
>
> Sutton
>

You could write the bootloader as a separate application that permanently lives in the first sector of flash.

On startup this application would run and look for a valid application on the SD card if found it would flash starting it to the second sector. (or whatever sector you decide you want your application to live)

If no SD card was found it checks if the current "application" is valid and jump to the start of it.

If no SD card is found and the current "application" is invalid you remain in the bootloader application indefinately.

This does mean you may need to do some post processing on the applications raw binary image created by your compiler to calculate a checksum, pad out the length and append the checksum to the image. As well you may need to tweak some options to the application to compile properly into a different sector of flash.

Basically once you get this bootloader debugged and stable and programmed on the part you never overwrite it. Any corrupted upgrade is only to the "application" and you bootloader is always there. Worst case a user needs to cycle power to the board.

I've used this basic idea on several bootloaders on lpc21xx parts, the only difference was that my upgrade came from a PC over a serial connection to the UART. Not sure how much code space is required for accessing an SD card so worst case you may need a few sectors for your bootloader.

Regards,
Mike

________________________________
From: l... [mailto:l...] On Behalf Of Sutton Mehaffey
Sent: Friday, July 31, 2009 4:41 PM
To: l...
Subject: Re: [lpc2000] Writing your own Bootloader - tips needed

Because I don't have enough room. I'm using most of the RAM.

Ananda Regmi wrote:
> Instead of overwriting the old bood loader why not transfer your boot
> loader
> code to RAM and run it from there.
>
> On Fri, Jul 31, 2009 at 2:58 PM, Sutton Mehaffey
> > wrote:
>
> >
> >
> > I have never written my own bootloader, but I've just about finished
> > writing all the code I need. I need to make sure I'm not missing
> anything.
> > So, any tips from others who have done this is greatly appreciated.
> >
> > My application is for a 'dumb' user to be able to upload new
> firmware via
> > SD card to a LPC2148 as new features to our product become
> available. I have
> > an intermediary serial flash that I upload to prior to writing to
> CPU Flash.
> > And, I gather that I must write to CPU RAM first, because there is
> only an
> > IAP command to write from RAM to FLASH. So, I use the top 1K of RAM
> as my
> > write buffer.
> >
> > If my upload crashes for some reason, my bootloader code has all the
> > routines in it to completely restart from scratch the upload process. If
> > this happens, does the user have to open up the system and ground
> P0.14 and
> > press RESET in order to start the bootloader OR is there another
> way? I'd
> > like to recover without the user getting inside the system to the
> circuit
> > board, if possible.
> >
> > The upload from the SD to serial flash works perfect with a sanity
> check,
> > then I write protect the flash. I haven't tested the code to
> actually start
> > overwriting the FLASH, because I wanted to make sure I had everything
> > covered.
> >
> > All of my bootloader routines are contained in 'bootload.c'. Using
> Keil's
> > uVision, how do you put that entire file with all it's routines at
> > 07FFFD000?
> >
> > Also, in case of a complete crash, is there a way to get back the old
> > bootloader (V2.12) that is currently built into the LPC2148?
> >
> > Anything else I need to know? Probably....
> >
> > Thanks in advance.
> >
> > Sutton
> >
> >
> >

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
800-207-6269, 770-514-7999, 770-514-1285 FAX
s...@lookoutportablesecurity.com