> I have the following doubts:
>
> 1) Is this framework reasonable?
Yes. I make the same thing except that firmware is write on internal
flash directly.
> 2) Do the LPC 2366 IAP commands work successfully?
Does anyone here
> have used them ?
Yes, of course. Must prepare sectors for erase/write then
erase/write. My firmware update app send a command to erase all flash
(except sector 0, where bootloader resides) then start to send blocks of
data to write on flash.
>
> 3) I have found that the KEIL generates a HEX file of the
> application. What other format I could also use? Does KEIL also
> generate a binary image? There exists an free tool to convert the HEX
> image file to a binary format ?
Yes. Search google for 'hex2bin.exe'. I think that keil has an
free
tool on their website. >
> 4) Did I miss something that will prevent the ISP from running after
> the bootloader process?
Maybe you firmware need to remap vectors to RAM. Maybe you need to
start your firmware at address 0x1000. First sector (0x0000 to 0x0fff) is
sector 0, which is not erased. >
> 5) Does LPC2366 IAP commands work with PLL turned on?
Reply by mjames_doveridge●March 20, 20082008-03-20
I do something similar with 2129.
>
> The bootloader framework is:
>
> 1) Place the bootloader code on a proctected area at sector 0 of the
> ARM flash. The bootloader (main()) will always run after a reset
> interrupt.
Yes - my bootloader always runs after a hard reset or power-cycle,
unless the ISP 'P0.14' built-in bootloader runs first.
> 2) Use the VIC and remap IRQ/FIQ ISR address at
bootloader and
> firmware startup.
If my secondary bootloader detects a valid, runnable image, it will
jump to it unless a key on the keypad is held down, in which case it
runs its own user interface so it can be told what to do.
> 3) The firmware image will be stored on an external
ATMEL FLASH
> memory prior the bootloader process. This process will be ccomplished
> by the firmware application. The bootloader only will be invoked to
> replace the firmware code if the external flash image was generated
> successfully.
I use an SD card, but similar.
> 4) The firmware image from the external flash will be
transfered by
> the booltoader to the arm flash using IAP commands.
Yes - same here.
> 5) The bootloader will run the firmware application
using a jump to a
> fixed flash location (firmware main()) only if the flash was updated
> with sucess.
I have a memory section of one sector at the top of flash that the IAP
loads with the version number, date, start-addr, checksum etc. of the
image. My boot checks this after the IAP load to see if everything is
OK. Actually, in my app, there are two sectors and two images - I
have enough flash to store two runnable banks. If, in the field, an
'upgrade' is found to have a 'new unacceptable feature not seen
during
testing', the user can boot the other bank containing the previous
version. This means that I have to build my app twice at two
different locations and distribute the code in 'Bank A' and 'Bank
B'
pairs, so allowing the bootloader to load the new image into whichever
bank happens to contain the oldest image to overwrite.
>
> I have the following doubts:
>
> 1) Is this framework reasonable?
Well, something very similar works fine on 2129 :)
> 2) Do the LPC 2366 IAP commands work successfully?
Does anyone here
> have used them ?
? don't use it.
> 3) I have found that the KEIL generates a HEX file of
the
> application. What other format I could also use? Does KEIL also
> generate a binary image? There exists an free tool to convert the HEX
> image file to a binary format ?
I use an Motorola S-file. The bootloader interprets this and blows
the appropriate sectors. If I use a 'simple' binary image, I would
lose control over location & be unable to use two banks.
> 4) Did I miss something that will prevent the ISP
from running after
> the bootloader process?
Not on 2129. I can still reflash over 'P0.14' serial if I want to
upgrade my bootloader.
> 5) Does LPC2366 IAP commands work with PLL turned
on?
Don't know. On my 2129, they do work, sort of. The code goes in but
the IAP takes a LONG TIME. If the PLL is off, it's much faster!
Suck it & see?
> 6) Any Comments?
Good luck!
Rgds,
Martin
Reply by ●March 20, 20082008-03-20
Hello,
I am starting to develop a bootloader for the LPC 2366 processor. The
IDE is the KEIL RealView.
The bootloader framework is:
1) Place the bootloader code on a proctected area at sector 0 of the
ARM flash. The bootloader (main()) will always run after a reset
interrupt.
2) Use the VIC and remap IRQ/FIQ ISR address at bootloader and
firmware startup.
3) The firmware image will be stored on an external ATMEL FLASH
memory prior the bootloader process. This process will be ccomplished
by the firmware application. The bootloader only will be invoked to
replace the firmware code if the external flash image was generated
successfully.
4) The firmware image from the external flash will be transfered by
the booltoader to the arm flash using IAP commands.
5) The bootloader will run the firmware application using a jump to a
fixed flash location (firmware main()) only if the flash was updated
with sucess.
I have the following doubts:
1) Is this framework reasonable?
2) Do the LPC 2366 IAP commands work successfully? Does anyone here
have used them ?
3) I have found that the KEIL generates a HEX file of the
application. What other format I could also use? Does KEIL also
generate a binary image? There exists an free tool to convert the HEX
image file to a binary format ?
4) Did I miss something that will prevent the ISP from running after
the bootloader process?
5) Does LPC2366 IAP commands work with PLL turned on?
