Hello everyone,

In the past few days I've been doing some research on bootloaders for
the LPC. I think that for my application the most effective approach
would be to use a "second-stage" bootloader that can be executed from
the main program. My basic idea is this:

The main bootloader code would reside in flash near the top end. In
this way the code in the lower region of flash can be programmed
without affecting the bootloader. The job of the flash functions is
to manage communications and overall bootloader operation. There
would be a few small functions for the actual write/erase IAP
operations that reside in RAM.

When the command to enter bootloader mode is called the following
would occur:

Enter bootloader function
Safely stop all device functions
Disable all interrupts, WDT
Disable PLL
reset uart baud
wait for command

I don't see the need for interrupts in a bootloader since there are no
other tasks to worry about. I do intend to use the bootloader with a
RTOS based system, will this cause any problems? If all the
interrupts are disabled there should never be a call to switch tasks,
and after a successful firmware update the CPU must be reset anyways.

The bootloader would probably write one sector at a time. The code
would use a large portion of RAM as a buffer. Being that this
application is sure to use a lot of RAM this buffer would also
certainly corrupt some of the main program memory, but this shouldn't
matter since the CPU will need to be reset anyway.

To me this seems to make sense. But I've got a few questions:
How can I ensure that the sector buffer does not collide with the RAM
functions or any other variables used by the bootloader?

Do I need to worry about any of the exception vectors in bootloader
mode? What is a good way to reset the CPU via software? I thought
there was some sample code for IAP functions. Where can I find this?
Any ideas on how to handle the case where the bootloader is
interrupted? Have I made any huge oversights? I use Rowley
Crossworks. Whatever advice you can provide is greatly appreciated. Start a New Thread

--- In l..., "drproton2003" wrote:
>
> Hello everyone,
>
> In the past few days I've been doing some research on bootloaders for
> the LPC. I think that for my application the most effective approach
> would be to use a "second-stage" bootloader that can be executed from
> the main program. My basic idea is this:
>
> The main bootloader code would reside in flash near the top end. In
> this way the code in the lower region of flash can be programmed
> without affecting the bootloader. The job of the flash functions is
> to manage communications and overall bootloader operation. There
> would be a few small functions for the actual write/erase IAP
> operations that reside in RAM.
>
> When the command to enter bootloader mode is called the following
> would occur:
>
> Enter bootloader function
> Safely stop all device functions
> Disable all interrupts, WDT
> Disable PLL
> reset uart baud
> wait for command
>
> I don't see the need for interrupts in a bootloader since there are no
> other tasks to worry about. I do intend to use the bootloader with a
> RTOS based system, will this cause any problems? If all the
> interrupts are disabled there should never be a call to switch tasks,
> and after a successful firmware update the CPU must be reset anyways.
>
> The bootloader would probably write one sector at a time. The code
> would use a large portion of RAM as a buffer. Being that this
> application is sure to use a lot of RAM this buffer would also
> certainly corrupt some of the main program memory, but this shouldn't
> matter since the CPU will need to be reset anyway.
>
> To me this seems to make sense. But I've got a few questions:
> How can I ensure that the sector buffer does not collide with the RAM
> functions or any other variables used by the bootloader?
>
> Do I need to worry about any of the exception vectors in bootloader
> mode? What is a good way to reset the CPU via software? I thought
> there was some sample code for IAP functions. Where can I find this?
> Any ideas on how to handle the case where the bootloader is
> interrupted? Have I made any huge oversights? I use Rowley
> Crossworks. Whatever advice you can provide is greatly appreciated.
>

Hello,

SILL as distributed (freely) is a second stage boot loader. You can
find out more here:

http://water.cse.unsw.edu.au/~jayas/esdk/sill.html

Jaya Start a New Thread

--- In l..., "jayasooriah" wrote:
Correction: URL is http://www.cse.unsw.edu.au/~jayas/esdk/sill.html

>
> Hello,
>
> SILL as distributed (freely) is a second stage boot loader. You can
> find out more here:
>
> http://water.cse.unsw.edu.au/~jayas/esdk/sill.html
>
> Jaya
> Start a New Thread

--- In l..., "drproton2003"
wrote:
>
> Hello everyone,
>
> In the past few days I've been doing some research on bootloaders
for
> the LPC. I think that for my application the most effective
approach
> would be to use a "second-stage" bootloader that can be executed
from
> the main program. My basic idea is this:
>
> The main bootloader code would reside in flash near the top end. In
> this way the code in the lower region of flash can be programmed
> without affecting the bootloader. The job of the flash functions
is
> to manage communications and overall bootloader operation. There
> would be a few small functions for the actual write/erase IAP
> operations that reside in RAM.
>
> When the command to enter bootloader mode is called the following
> would occur:
>
> Enter bootloader function
> Safely stop all device functions
> Disable all interrupts, WDT
> Disable PLL
> reset uart baud
> wait for command
>
> I don't see the need for interrupts in a bootloader since there are
no
> other tasks to worry about. I do intend to use the bootloader with
a
> RTOS based system, will this cause any problems? If all the
> interrupts are disabled there should never be a call to switch
tasks,
> and after a successful firmware update the CPU must be reset
anyways.
>
> The bootloader would probably write one sector at a time. The code
> would use a large portion of RAM as a buffer. Being that this
> application is sure to use a lot of RAM this buffer would also
> certainly corrupt some of the main program memory, but this
shouldn't
> matter since the CPU will need to be reset anyway.
>
> To me this seems to make sense. But I've got a few questions:
> How can I ensure that the sector buffer does not collide with the
RAM
> functions or any other variables used by the bootloader?
>
> Do I need to worry about any of the exception vectors in bootloader
> mode? What is a good way to reset the CPU via software? I thought
> there was some sample code for IAP functions. Where can I find
this?
> Any ideas on how to handle the case where the bootloader is
> interrupted? Have I made any huge oversights? I use Rowley
> Crossworks. Whatever advice you can provide is greatly appreciated.
>

This issue has come up a couple of times. Rather than repeat
suggestions, see messages

http://tech.groups.yahoo.com/group/lpc2000/message/21390

and

http://tech.groups.yahoo.com/group/lpc2000/message/21386

There's several other messages in this thread that cover likely
issues.

See the User Manuals for a descrpotion of how IAP calls work: they're
easy enough to use if you follow all the requirements mentioned.

To answer your specific question on reset, the best way is to use the
watchdog, as this ensure a complete hardware reset of all
peripherals, which is difficult (impossible?) to achieve with a
software only approach.

Brendan Start a New Thread