Post by thread:PIC24 bootstrap loader implementation

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

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: {Quote hidden}> 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 > >

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: {Quote hidden}> 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 >> >> >>

Well, I took a different approach. Microchip is having the bootloader reprogram the reset vector and the interrupt vector table. As I recall, the 24H series lets you write protect a boot section that starts at 0. So, if your bootloader is going to write stuff down at 0, besides overwriting the reset vector (sounds like a bad idea to me), it could overwrite the bootloader itself, since you will not be able to write protect that. What I did is to put the bootloader from 0x200 to 0x7ff. There is a goto the start of my application at 0x800. Right above that is a jump table for all the interrputs, whether I'm using them or not. The reset vector points to my bootloader, which checks a switch. If the switch is not closed, we go to 0x800, then to the start of the application. Everything below 0x800 is write protected. The bootloader I currently have in two products using the 24H does bootloading over Ethernet. Using an HTTP POST, the hex file for the application (addresses 0x800 and above) is sent to the PIC. It is parsed by the PIC and stored in external SPI flash. After the whole file is received without error, the bootload code in the boot section is called. Note that when the boot section is write protected, only the first few addresses (I think it's 32) in the section can be reached by a goto from another section. So, there's a goto in these early addresses that points to the actual code in the boot section. Also, interrupts are strange when executing in a secure segment, so I disable them. Anyway, once I have the code in SPI flash, I copy it to PIC flash using the code in the boot section of the PIC. In the unlikely event that this fails (perhaps bad code sent to the SPI flash), the user can hold a switch on power-up that copies the original code from SPI flash back to the PIC. During production, the PIC code that was loaded is copied out to SPI flash. The bootloader is just another module in the application instead of being a separate project. Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available!

No, but I have had situations where the process had to be repeated for whatever reason in the field. Just make sure the bootloader can't be written to, and that there is always a non-application-required method to start the bootloader (a hardware switch, two pin jumper input, a time where the bootloader waits for a character over the uart, etc. - just something that doesn't require the application to be running to initiate a the loading of a program), and that you create and check some sort of checksum for the application so that the bootloader can verify that it's o.k. to dive before jumping. I don't mean to make the process sound easy, it's not, and you have to do a good bit of planning to catch all the possible problems so when I say I have had no "paperweight" problems in the field, I have had lots of problems on the bench before it ever got there. Tony Mark E. Skeels wrote: {Quote hidden}> 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 >>> >>> >>> >>>