Tom Walsh wrote:
>Richard Duits wrote:
>
>
>
>>I implemented a second stage bootloader in the first flash sector that
>>is able to update the flash via a FTDI FT245 usb link. The bootloader
>>checks a signature (a CRC is also possible) and if this is correct, it
>>starts the program from the second flash sector. The program can jump to
>>a fixed address (immediately after the exception vectors) to erase the
>>program and start an update procedure.
>>
>>If the update fails, my own bootloader in the first sector will not
>>start the program in the second sector because of an incorrect signature
>>or crc and it will run in update mode until a correct program is
uploaded.
>>
>>A disadvantage is that you need to relocate the exception vectors to ram
>>or use the fixed exception vector table from the bootloader. Another
>>disadvantage is (at least with the keil ide) is that the debugger / jtag
>>flash programmer does not know how to handle a program that does not use
>>sector 0 which I solved by always including the bootloader code in the
>>ide project.
>>
>>
>>
>>
>>
>I've done something similar. I reserved the upper 80K of flash for use
>of a resident bootloader. The board has two processors: LPC2106 +
>LPC2138. Either processor may place the other into ISP programming mode
>and program the other processors' flash memory. An integral part of
>this approach is that the SD card will always have a copy of the current
>program of each processor. The LPC2138 bootloader knows how to read the
>SD filesystem.
>
>To do field updates, the end-customer replaces the two binary image
>files and manually invokes the Update mode of the system. The LPC2106
>is where the Update mode would be initiated from, that processor informs
>the LPC2138 to begin the upgrade cycle.
>
>Once the LPC2138 is told to do a system upgrade, it reprograms the IVECT
>table (address 0) and forces a full system reset (hardware line to RESET
>circuit). When the LPC2138 boots, it boots into the resident loader.
>The loader will now go through the process of erasing and reprogramming
>the LPC2106. After it successfully completes that, it then reprograms
>it's main flash (all flash between the sector 0 and the resident loader
>is erased). When the LPC2138 main program has been programmed, as the
>last thing, it will relocate the IVECT table into RAM and program sector
>0. Then the LPC2138 forces a final system reset.
>
>A bit complicated, but it does work. I needed some way to keep special
>software on a laptop out of the equation. Trouble with field personnel
>is that there is a wide disparity of technical competence when it comes
>to computers. Also, we wanted to keep from "owning" the laptop /
>computer by installing our own programming software onto it. From
>experience, if you give the end-user a programming tool to install on
>their Windows computer, someone will give you grief about "your
software
>screwed my computer up, tell me how to fix it!". :(
>
>I do need to finish the bootloader scheme and have the LPC2106 processor
>conditionally reprogram the IVECT table at sector 0 of the LPC2138.
>This way, if the final step of the LPC2138 upgrade cycle fails (LPC2138
>replacing vectors at sector 0), the LPC2106 can physically force another
>cycle. Since the two processors talk to each other over UART0, failure
>to establish a connection within a proscribed interval would trigger this..
>
>So far, the upgrade mechanism is working ok.
>
>
>
Just a further note. It would be nice if we could protect a sector so
that it would be impossible to use the IAP commands to reprogram that
sector. Make it a command that is only available via the ISP to lock /
unlock protection on a specific sector. If IAP attempts to erase /
write that sector, it would unconditionally fail.
Philips, add that to my wish list?
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net,http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
Richard Duits wrote:
>I implemented a second stage bootloader in the
first flash sector that
>is able to update the flash via a FTDI FT245 usb link. The bootloader
>checks a signature (a CRC is also possible) and if this is correct, it
>starts the program from the second flash sector. The program can jump to
>a fixed address (immediately after the exception vectors) to erase the
>program and start an update procedure.
>
>If the update fails, my own bootloader in the first sector will not
>start the program in the second sector because of an incorrect signature
>or crc and it will run in update mode until a correct program is uploaded.
>
>A disadvantage is that you need to relocate the exception vectors to ram
>or use the fixed exception vector table from the bootloader. Another
>disadvantage is (at least with the keil ide) is that the debugger / jtag
>flash programmer does not know how to handle a program that does not use
>sector 0 which I solved by always including the bootloader code in the
>ide project.
>
>
>
I've done something similar. I reserved the upper 80K of flash for
use
of a resident bootloader. The board has two processors: LPC2106 +
LPC2138. Either processor may place the other into ISP programming mode
and program the other processors' flash memory. An integral part of
this approach is that the SD card will always have a copy of the current
program of each processor. The LPC2138 bootloader knows how to read the
SD filesystem.
To do field updates, the end-customer replaces the two binary image
files and manually invokes the Update mode of the system. The LPC2106
is where the Update mode would be initiated from, that processor informs
the LPC2138 to begin the upgrade cycle.
Once the LPC2138 is told to do a system upgrade, it reprograms the IVECT
table (address 0) and forces a full system reset (hardware line to RESET
circuit). When the LPC2138 boots, it boots into the resident loader.
The loader will now go through the process of erasing and reprogramming
the LPC2106. After it successfully completes that, it then reprograms
it's main flash (all flash between the sector 0 and the resident loader
is erased). When the LPC2138 main program has been programmed, as the
last thing, it will relocate the IVECT table into RAM and program sector
0. Then the LPC2138 forces a final system reset.
A bit complicated, but it does work. I needed some way to keep special
software on a laptop out of the equation. Trouble with field personnel
is that there is a wide disparity of technical competence when it comes
to computers. Also, we wanted to keep from "owning" the laptop /
computer by installing our own programming software onto it. From
experience, if you give the end-user a programming tool to install on
their Windows computer, someone will give you grief about "your software
screwed my computer up, tell me how to fix it!". :(
I do need to finish the bootloader scheme and have the LPC2106 processor
conditionally reprogram the IVECT table at sector 0 of the LPC2138.
This way, if the final step of the LPC2138 upgrade cycle fails (LPC2138
replacing vectors at sector 0), the LPC2106 can physically force another
cycle. Since the two processors talk to each other over UART0, failure
to establish a connection within a proscribed interval would trigger this..
So far, the upgrade mechanism is working ok.
Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net,http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
Is there some example code of such second stage bootloader
that you use in your project?
Thanks in advance,
Srdan
--- In lpc2000@lpc2..., Richard Duits <yahoo@...> wrote:
>
> I only use the interrupt vector which jumps to the address read from
the
> VIC and the SWI vector, which jumps to a fixed
address. But you also
> copy your vectors to RAM and use the MEMMAP register to remap the
> interrupt vectors to RAM. Read the "MEMORY MAPPING CONTROL"
section in
> the user manual to see how this works.
>
> Richard.
>
>
>
> Srdan Suka wrote:
> > Thanks Richard
> >
> > This solution sounds ok and it seems better than use
> > ISP commands.
> > How did you solve the problem with reallocation
> > of exception vectors?
> >
> > Thanks again,
> >
> > Srdan
> >
> >
> >
> > --- In lpc2000@lpc2..., Richard Duits <yahoo@> wrote:
> > >
> > > I implemented a second stage bootloader in the first flash
sector that
> > > is able to update the flash via a FTDI
FT245 usb link. The
bootloader
> > > checks a signature (a CRC is also
possible) and if this is
correct, it
> > > starts the program from the second flash
sector. The program can
> > jump to
> > > a fixed address (immediately after the exception vectors) to
erase the
> > > program and start an update procedure.
> > >
> > > If the update fails, my own bootloader in the first sector will
not
> > > start the program in the second sector because of an incorrect
> > signature
> > > or crc and it will run in update mode until a correct program is
> > uploaded.
> > >
> > > A disadvantage is that you need to relocate the exception vectors
to
> > ram
> > > or use the fixed exception vector table from the bootloader.
Another
> > > disadvantage is (at least with the keil ide) is that the debugger
/
> > jtag
> > > flash programmer does not know how to handle a program that does
not
> > use
> > > sector 0 which I solved by always including the bootloader code
in the
> > > ide project.
> > >
> > > Regards,
> > > Richard.
> > >
> > >
> > > Srdan Suka wrote:
> > > > Hi everyone!
> > > >
> > > > I am using LPC2103 in my project. LPC is connected to server
using
> > > > RS485 interface (Semi-duplex). Also I have EEPROM memory
connected to
> > > > LPC.
> > > > I would like to do this if it is possible:
> > > >
> > > > 1. Using my resident LPC firmware, load new firmware to
EEPROM
memory.
> > > > 2. Load a small program into Flash
into first available sector
> > > > (this program I would like to use to copy new firmware
from
> > > > EEPROM to Flash over the existing firmware).
> > > >
> > > > Is it possible to use ISP GO command to execute "Copy
proggram" from
> > > > Flash to start copying firmware
from EEPROM to flash memory.
> > > > What will happen it copy process fails and I overwrite
firmware at
> > > > 0x0000 0000 address?
> > > > Can I "tell" the bootloader alwayws to start the
"Copy program"
> > unless I
> > > > "tell" it that the updating is finishead and the
main firmware
should
> > > > be started?
> > > >
> > > > Has anyone tried this?
> > > >
> > > > Thanks :)
> > > >
> > > > Srdan
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> >
> > SPONSORED LINKS
> > Microcontrollers
> >
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ>> > Microprocessor
> >
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA>> > Intel microprocessors
> >
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw>> >
> > Pic microcontrollers
> >
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw>> >
> >
> >
> >
> > >.
> >
> >
> >
> >
>
Reply by Richard Duits●March 9, 20062006-03-09
I only use the interrupt vector which jumps to the address read from the
VIC and the SWI vector, which jumps to a fixed address. But you also
copy your vectors to RAM and use the MEMMAP register to remap the
interrupt vectors to RAM. Read the "MEMORY MAPPING CONTROL" section in
the user manual to see how this works.
Richard.
Srdan Suka wrote:
> Thanks Richard
>
> This solution sounds ok and it seems better than use
> ISP commands.
> How did you solve the problem with reallocation
> of exception vectors?
>
> Thanks again,
>
> Srdan
>
>
>
> --- In lpc2000@lpc2..., Richard Duits <yahoo@...> wrote:
> >
> > I implemented a second stage bootloader in the first flash sector that
> > is able to update the flash via a FTDI FT245 usb link. The bootloader
> > checks a signature (a CRC is also possible) and if this is correct, it
> > starts the program from the second flash sector. The program can
> jump to
> > a fixed address (immediately after the exception vectors) to erase the
> > program and start an update procedure.
> >
> > If the update fails, my own bootloader in the first sector will not
> > start the program in the second sector because of an incorrect
> signature
> > or crc and it will run in update mode until a correct program is
> uploaded.
> >
> > A disadvantage is that you need to relocate the exception vectors to
> ram
> > or use the fixed exception vector table from the bootloader. Another
> > disadvantage is (at least with the keil ide) is that the debugger /
> jtag
> > flash programmer does not know how to handle a program that does not
> use
> > sector 0 which I solved by always including the bootloader code in the
> > ide project.
> >
> > Regards,
> > Richard.
> >
> >
> > Srdan Suka wrote:
> > > Hi everyone!
> > >
> > > I am using LPC2103 in my project. LPC is connected to server
using
> > > RS485 interface (Semi-duplex). Also I have EEPROM memory
connected to
> > > LPC.
> > > I would like to do this if it is possible:
> > >
> > > 1. Using my resident LPC firmware, load new firmware to EEPROM
memory.
> > > 2. Load a small program into Flash into first available sector
> > > (this program I would like to use to copy new firmware from
> > > EEPROM to Flash over the existing firmware).
> > >
> > > Is it possible to use ISP GO command to execute "Copy
proggram" from
> > > Flash to start copying firmware from EEPROM to flash memory.
> > > What will happen it copy process fails and I overwrite firmware
at
> > > 0x0000 0000 address?
> > > Can I "tell" the bootloader alwayws to start the
"Copy program"
> unless I
> > > "tell" it that the updating is finishead and the main
firmware should
> > > be started?
> > >
> > > Has anyone tried this?
> > >
> > > Thanks :)
> > >
> > > Srdan
> > >
> > >
> >
>
>
>
>
>
>
> SPONSORED LINKS
> Microcontrollers
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ>
> Microprocessor
>
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA>
> Intel microprocessors
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw>
>
> Pic microcontrollers
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw>
>
>
>
>
> >.
>
>
>
>
Reply by Srdan Suka●March 9, 20062006-03-09
Thanks Richard
This solution sounds ok and it seems better than use
ISP commands.
How did you solve the problem with reallocation
of exception vectors?
Thanks again,
Srdan
--- In lpc2000@lpc2..., Richard Duits <yahoo@...> wrote:
>
> I implemented a second stage bootloader in the first flash sector that
> is able to update the flash via a FTDI FT245 usb link. The bootloader
> checks a signature (a CRC is also possible) and if this is correct, it
> starts the program from the second flash sector. The program can
jump to
> a fixed address (immediately after the exception
vectors) to erase the
> program and start an update procedure.
>
> If the update fails, my own bootloader in the first sector will not
> start the program in the second sector because of an incorrect
signature
> or crc and it will run in update mode until a
correct program is
uploaded.
>
> A disadvantage is that you need to relocate the exception vectors to
ram
> or use the fixed exception vector table from the
bootloader. Another
> disadvantage is (at least with the keil ide) is that the debugger /
jtag
> flash programmer does not know how to handle a
program that does not
use
> sector 0 which I solved by always including the
bootloader code in the
> ide project.
>
> Regards,
> Richard.
>
>
> Srdan Suka wrote:
> > Hi everyone!
> >
> > I am using LPC2103 in my project. LPC is connected to server using
> > RS485 interface (Semi-duplex). Also I have EEPROM memory connected to
> > LPC.
> > I would like to do this if it is possible:
> >
> > 1. Using my resident LPC firmware, load new firmware to EEPROM memory.
> > 2. Load a small program into Flash into first available sector
> > (this program I would like to use to copy new firmware from
> > EEPROM to Flash over the existing firmware).
> >
> > Is it possible to use ISP GO command to execute "Copy
proggram" from
> > Flash to start copying firmware from EEPROM to flash memory.
> > What will happen it copy process fails and I overwrite firmware at
> > 0x0000 0000 address?
> > Can I "tell" the bootloader alwayws to start the "Copy
program"
unless I
> > "tell" it that the updating is
finishead and the main firmware should
> > be started?
> >
> > Has anyone tried this?
> >
> > Thanks :)
> >
> > Srdan
> >
> >
>
Reply by Richard Duits●March 9, 20062006-03-09
I implemented a second stage bootloader in the first flash sector that
is able to update the flash via a FTDI FT245 usb link. The bootloader
checks a signature (a CRC is also possible) and if this is correct, it
starts the program from the second flash sector. The program can jump to
a fixed address (immediately after the exception vectors) to erase the
program and start an update procedure.
If the update fails, my own bootloader in the first sector will not
start the program in the second sector because of an incorrect signature
or crc and it will run in update mode until a correct program is uploaded.
A disadvantage is that you need to relocate the exception vectors to ram
or use the fixed exception vector table from the bootloader. Another
disadvantage is (at least with the keil ide) is that the debugger / jtag
flash programmer does not know how to handle a program that does not use
sector 0 which I solved by always including the bootloader code in the
ide project.
Regards,
Richard.
Srdan Suka wrote:
> Hi everyone!
>
> I am using LPC2103 in my project. LPC is connected to server using
> RS485 interface (Semi-duplex). Also I have EEPROM memory connected to
> LPC.
> I would like to do this if it is possible:
>
> 1. Using my resident LPC firmware, load new firmware to EEPROM memory.
> 2. Load a small program into Flash into first available sector
> (this program I would like to use to copy new firmware from
> EEPROM to Flash over the existing firmware).
>
> Is it possible to use ISP GO command to execute "Copy proggram"
from
> Flash to start copying firmware from EEPROM to flash memory.
> What will happen it copy process fails and I overwrite firmware at
> 0x0000 0000 address?
> Can I "tell" the bootloader alwayws to start the "Copy
program" unless I
> "tell" it that the updating is finishead and the main firmware
should
> be started?
>
> Has anyone tried this?
>
> Thanks :)
>
> Srdan
>
>
Reply by Srdan Suka●March 9, 20062006-03-09
Hi everyone!
I am using LPC2103 in my project. LPC is connected to server using
RS485 interface (Semi-duplex). Also I have EEPROM memory connected to
LPC.
I would like to do this if it is possible:
1. Using my resident LPC firmware, load new firmware to EEPROM memory.
2. Load a small program into Flash into first available sector
(this program I would like to use to copy new firmware from
EEPROM to Flash over the existing firmware).
Is it possible to use ISP GO command to execute "Copy proggram" from
Flash to start copying firmware from EEPROM to flash memory.
What will happen it copy process fails and I overwrite firmware at
0x0000 0000 address?
Can I "tell" the bootloader alwayws to start the "Copy
program" unless I
"tell" it that the updating is finishead and the main firmware should
be started?
Has anyone tried this?
Thanks :)
Srdan
