Thanks, Tony.

You ever have any problems with the bootloader getting scrambled in the 
field, or a customer turning his device into a paperweight while trying 
to update firmware?

Mark

Tony Vandiver wrote:
> The only thing I would add is that it gives me the warm fuzzies to know 
> that my bootloader actually worked in test before it went out the door.  
> Because of that, I only put the bootstrap in through the ISP, and in 
> test, I use the bootstrap to program in the application.  By doing that, 
> I've tested the hardware required to do the bootloading in the field, 
> where otherwise, I'd have to set up some kind of loopback test for 
> production to validate the UART or whatever is being used.  It's also 
> easier to make updates in production since I can just give them the same 
> application that I'm publishing for use in the field instead of having 
> to go back and compile the two programs on top of each other in the same 
> memory space generating a unique file that's not used anywhere else.  
> You also might want to think about encryption if you're worried about 
> security.  Just my $0.02.
>
> Tony
>
>
> Mark E. Skeels wrote:
>   
>> Hello, PIClist.
>>
>> After working my way through App note AN1094 
>> <http://ww1.microchip.com/downloads/en/AppNotes/01094a.pdf> it appears 
>> that to set up this bootloader I need to
>>
>>     * Modify the sample bootloader target app to use the proper UART for
>>       my hardware.
>>     * Modify the bootloader linker script for my PIC24 to place
>>       bootloader code at 0x400.
>>     * Build the target bootloader app in MPLab using the above linker
>>       script for my PIC.
>>     * Program it into the PIC24.
>>     * Modify/Add the directives on p. 6 of the app note to the linker
>>       file for my PIC24 main application  to load code at _0xc00_ and
>>       also to specify the absolute delay _location_ and _value_ for the
>>       bootloader and put it in the memory map at 0xc00.(***)
>>     * Build my main PIC24 app using the second modified linker script.
>>
>> At this point, I could use my PIC24 hardware with installed bootloader 
>> and the supplied Windows console bootloader app to load my application 
>> into the PIC24 hardware, or I could somehow combine the two hex files 
>> into one and program the entire thing in production.
>>
>>    1. Does that sound right/anything I missed?
>>    2. Do I need to consider any other factors or gotchas?
>>    3. Anybody use this in a production environment and have comments or
>>       insights?
>>
>> Thanks PICsters,
>> Mark
>>
>> (***)
>>
>> /(modify /ORIGIN/ and /LENGTH/ in this line) /program (xr) : ORIGIN = 
>> 0xC00, LENGTH = 0x29E00
>> /(modify /CODE_BASE/ value in this line) /__CODE_BASE = 0xC00; /* 
>> Handles, User Code, Library Code */
>> /*
>> ** User Code and Library Code
>> */
>> .text __CODE_BASE :
>> {/
>> (add this line) /SHORT(0x0A); /* Bootloader timeout in sec */
>> *(.handle);
>> *(.libc) *(.libm) *(.libdsp);
>> *(.lib*);
>> *(.text);
>> } >program
>>
>>   
>>     
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist