'PIC24 bootstrap loader implementation'
Mark E. Skeels
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
* 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
/(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 */
*(.libc) *(.libm) *(.libdsp);
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.
Mark E. Skeels wrote:
Mark E. Skeels
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?
Tony Vandiver wrote:
|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.
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
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
Mark E. Skeels wrote:
More... (looser matching)
- Last day of these posts
- In 2009
, 2010 only
- New search...