When speaking about good bootloader product for Microchip’s various MCU product series, I put my two cents in “ds30 Loader” from Mikael Gustafsson. However, “ds30 Loader” is no longer available for free to support Micorchip’s latest 70MHz dsPIC33E/PIC24E products. If you have determined to develop your own bootloader for them, this article could be a reference that you might be looking for. First of all, let’s take a look at Mikael Gustafsson‘s opensource “ds30 Loader” and then, graduate to your own version of that.
1. Bootloading ABC:
Bootloader itself is essentially one piece of firmware that is stored in the MCU’s flash. Unlike normal application firmware, bootloader’s job is to install a new incoming firmware into is own flash when necessary. Or，let’s put it another way: A micro-controller with bootloader is capable of programming itself. Except for that, it is invisible, that is, you don’t even notice its existence, and the MCU runs just exactly same way as a chip that is burned by a regular programmer. Rule of thumb, the size of firmware must be as small as possible because it also eats your flash. A great advantage of bootloader is that you no longer need a programmer once the bootloader is burned into its flash. This gives the bootloader a very tough challenge — it must be very reliable, or at least, it couldn’t erase or destroy itself by accident.
2. Where and how to place the bootloader:
There are some discussion over where to put the bootloader. Products like “ds30 Loader” use the last user program flash memory block to store the bootloader firmware, others like Microchip’s official “AN1094 – Bootloader for dsPIC30F/33F and PIC24F/24H Devices” put bootloader at the beginning of user memory block, right after the IVT (Interrupt Vector Table, which locates in the first program block of User Program Flash Memory). I personally prefer “ds30 Loader”‘s solution simply because an end user pays zero attention to the booloader when working on his/her own application firmware. In another case, a firmware engineer must specially configure your IDE to avoid overwriting the first user program flash block.
Figure 1. A normal without bootloader. Compiler converts your design into binary that uses the very first available flash space in your chip. GOTO will be modified to jump to the beginning of your firmware
Figure 2. An architecture in which bootloader is placed at the beginning of the flash space. Technically, bootloader is not placed at the very beginning of the flash space because “GOTO”, “RESET” and “IVT” are already there. Usually, the bootloader is placed in the 2nd program block (erase block) of the flash. Compiler must avoid using the 2nd block so special attention must be paid to configure the compiler. Another disadvantage of this architecture is that, you may have to lose the space right after the IVT because flash is always treated with the minimum unit of block when being erased. “GOTO”, “RESET” and “IVT” are in the 1st block, but not occupying 100% of that, actually not even close to that. A normal compiler will start using the flash space right after IVT, but in this case, compiler will have to skip the whole 1st block and 2nd block. If you really want that little space back, it is still possible, but requires more complex configuration to your compiler.
Figure 3. An architecture with bootloader at the end of flash space. So the compiler converts your design in its normal way that uses the first available space right after IVT, no special configuration for the compiler is needed. And you don’t lose anything in the 1st program block. Of course, you must keep in mind that your application mustn’t be too long, otherwise it will overwrite the last block of bootloader. And you can’t save the free space in the last block that is not being used by the bootloader (most likely this will never happen).
You can avoid using programmer any more after bootloader is there. However, before you have it there, you will have to use the programmer to burn the bootloader once. Yes, it is only once!