Em 26/3/2011 13:46, Harold Hallikainen escreveu:
>> You can always try Microchip forum which has many more PIC
>> related topics.
>>
>> I do not use PIC24/dsPIC myself. But in the following Microchip forum
>> thread, I have collected many bootloaders related to PICs.
>> http://www.microchip.com/forums/m424874.aspx
>>
>> This one seems to be quite good (written in assembly).
>> http://mrmackey.no-ip.org/elektronik/ds30loader/downloads.php
>>
>> --
>> Xiaofan
> I had a look at ds30loader, but did not see a linker script, so it's
> difficult to determine how memory is organized.

Yes, a custom linker-script is essential for a boot-loader. You need to
ensure everything is allocated at known addresses that won't be moved at
each rebuild.


>  In my PIC24H bootloaders,
> I do the following:
>
> 0x0000 - goto code in boot section (under 0x200) that checks a switch or
> whatever else is used to determine if we want to run application or
> bootload.


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.


> 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.


> 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.


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.


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.

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.


> 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.


> 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

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.