Thanks for the comments!


>
> Usually I leave for the application to decide when to invoke the
> boot-loader. The external switch is kept just as a fail-safe mechanism
> for when the application ceases responding.

I agree. On larger applications where a firmware update is possible over
USB, TCP, or HTTP POST, the update is handled entirely by the application.
The switch check is done in smaller bootloaders (like for 18 series) or as
a restore switch as discussed below.

>
>
>> Between 0x0000 and 0x0200 is bootloader code. All interrupt vectors
>> point
>> to a jump table that starts above 0x0200.
>
>
> I started using this approach but desisted after seeing the huge amount
> of necessary hand-editing of the linker-script.
>

Yes, there was editing of the linker script (which seem to be lightly
commented and hard to read), but once it's done, it's done.

>
>> 0x0200 - goto application start. This includes stack initialization,
>> variable initialization, etc., as generated by PIC24 C compiler.
>>
>> Right above 0x0200 is the interrupt jump table. The compiler can rewrite
>> this.
>

I was incorrect on this address. The 0x200 is for my 18 series stuff. I
think it's 0x800 for PIC24.

>
> It would be good to reserve from 0x00000 up to 0x003ff for the
> boot-loader, because each erase block is 512 instructions =3D=3D 1k
> addresses =3D=3D 1536 bytes. The first erase block ends at 0x003ff.
>

Yes, as above, I was mistaken. It's 0x800.

>
> The problem with this approach is that your applications must be adapted
> to be boot-loaded. It must be linked in a way that it doesn't superposes
> to the boot-loader areas.
>

Yes, since the bootloader is included in the application project (and the
modified linker script), this is not an issue. The entire project MP3
environment is put in the production MP3 programmers.

> I adopted and adapted the method of Microchip's TCP/IP boot-loader,
> where the boot-loader resides in the very end of the FLASH and it
> replaces the reset vector (goto instruction) of the application with its
> own reset vector, keeping the original application's reset vector in a
> separate area.
> It is good because it allows any application (even old or built with
> other compilers) to be boot-loaded, as long as it doesn't fill too much
> the program memory and superposes the boot-loader itself.
>

I'm concerned about the bootloader being overwritten. Also, since the
application directly overwrites the reset and interrupt vector table, it
seems dangerous is something goes wrong.

>
>> The bootloader is included in the application project. If I need to send
>> out code to be bootloaded in the field, I use file - export to export a
>> hex file that starts at 0x200.
>
>
> But then you can only boot-load applications made for the boot-loader.
>

That's true. I don't expect other applications to be put into our product.


>
>> If the bootloader uses a uart, the entire bootloader code is in the
>> space
>> under 0x200. If the bootloader uses TCP, HTTP POST, or USB, the
>> application handles most of the work.
>
>
> That the approach I am using now.
>
>
>>  It writes to SPI flash as a buffer.
>
>
> I use half of the internal FLASH.
>
>
>> When the copy to external flash is complete, the application calls a
>> function in the boot section (under 0x200) that copies the external
>> flash
>> to internal flash, starting at 0x200. Because the application that was
>> used to load the new code is now being overwritten, there is a chance of
>> things going wrong leaving corrupt code in the application area so stuff
>> could not be reloaded. To deal with this problem, I keep a copy of the
>> factory installed code in external flash also. The user can hold down a
>> couple front panel buttons during power up to copy that factory code
>> back
>> in to internal flash (starting at 0x200).
>
>
> I do things differently, but the basic idea is similar.
>
>
>> I've done  a similar thing with the PIC32, putting the boot stuff in the
>> boot flash of the PIC32.
>>
>> Harold
>
>
> Best regards,
>
> Isaac

Again, THANKS for the comments! There are certainly different ways of
doing things, and they are all valid.

Harold




--=20
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.