Skip to main content
Topic: bootloaders (Read 3361 times) previous topic - next topic

bootloaders

With the talk of a new bootloader for the buspirate i did some looking around.

there are a few different ones out there. more than i imagined.

check http://www.opensourcepic.org/bootloader.php for one source of bootloaders.

to me the "scene Double" bootloader is very interesting.
check http://direction.scene-double.com/2008/ ... llers.aspx

It allows updating from any recent OS via USb without any apps. looks like a memory device to the OS. cool idea.

anyway. i thought it might be interesting to someone. please feel free to move if required.

Re: bootloaders

Reply #1
That's the one I'm using for this months project, the USB IR toy :)
Got a question? Please ask in the forum for the fastest answers.

Re: bootloaders

Reply #2
I'd like to start a more in-depth discussion about PIC bootloaders, since I've written my own and I have some issues with the Microchip bootloader.

One simple issue is that the Microchip bootloader branched off a copy of the USB stack before a lot of bugs were fixed. I painstakingly compared the two source trees and found that many of the bug fixes in the main USB stack were also applied to the bootloader, but this seems like a fragile way to maintain code. Perhaps it is an issue of size, where including a full USB stack in a bootloader would make it too large. I did get the vague impression that Microchip may have had a reason for branching off the USB code, to avoid making the bootloader grow in size as the main USB stack gained features. Anyone have any comments or experience here?

Another simply issue is that the Microchip bootloader requires the user to disconnect the USB cable and hold a button in order to enter firmware update mode. Perhaps this makes things more secure, since that's unlikely to happen by accident, but it sure seems like something I wouldn't want to mess with as a user.

Then we get into more complicated ideas:

1) I wonder about the tradeoff between size, code reuse, and reliability and how this affects the bootloader source versus the USB stack source. My starting assumption is that any bootloader with USB support is surely going to be used for firmware that also supports USB, although I suppose it would be possible to design a completely standalone firmware (i.e. no USB) which only uses USB for firmware upgrades. Anyway, my thought here is that you have a couple of choices:

A) The Microchip way is to embed two copies of the USB stack in your total firmware. One is part of the bootloader, is small, and is based on old code. The advantages are that the bootloader itself is probably as small as possible since it does not support any unneeded USB features. Also, you have the advantage that old code is stable code, and you can depend upon your bootloader working because it's unlikely that new bugs will be found in old code, especially compared to new bugs appearing in code that's constantly changing. Plus, the size is predictable. The disadvantage is that the main firmware cannot really reuse any of the USB code because they're completely independent.

B) An approach that I investigated is to use a function jump table so that the main firmware can call into the bootloader and reuse the USB stack. This makes the total firmware size smaller, because there is only one copy of each USB function and data. Theoretically, you're not even stuck with the old USB stack, because the function jump table allows the main firmware to override any function (or even all functions) that need bug fixes. The disadvantage is that the bootloader section of the code is larger when you compile in a complete and modern USB stack. Also, it seems like the bootloader would be more susceptible to bugs unless this sort of design were tested and the USB stack stopped changing. I'm assuming that the bootloader cannot be self-updated, so bugs in the bootloader could not be fixed as easily as bugs in the main firmware.

2) Another big issue for me - and it might be due to my cycle-counting nature as someone who started programming on a 1 MHz 8-bit - is that the Microchip bootloader takes over low memory in the PIC, and forces every interrupt to waste cycles on an extra jump instruction.  The Microchip design requires main firmware to be written differently in order to use it with their bootloader. Theoretically, the Microchip way might be safer, since the low-memory section of Flash is never erased, but it sure seems like a bad design.

An approach that I investigated was to move the bootloader image up to the top part of memory, just below the Config bytes. This allows the firmware to be compiled at the same offset whether it uses the bootloader or not. It also allows interrupts to be in-place, or with only a direct jump instead of an indirect jump. The problem here is that firmware upgrades require a multistage process to prevent leaving the Flash in an unusable state after low-memory is erased. I came up with a few good ideas here but my client ran out of funding for further development.

3) As mentioned above, I have written a bootloader which can be used without requiring the user to press a button, and especially without requiring the USB cable (and power) to be cycled. I think this should make Flash updates safer, and certainly more convenient. USB allows software disconnect, and a good operating system will not get confused when the firmware changes even though the USB cable remains attached.


Does anybody have any comments on the above? How many of you are hand-coding assembly interrupt routines to minimize the number of cycles spent in interrupts? How many of you think that it matters how the bootloader is implemented when it comes to the above?

Re: bootloaders

Reply #3
My thoughs about an USB bootloader (no experience with USB but I helped with the buspirate one):

it should be as simple and small as possible (less code, less bugs) however USB is fairly complex compared to an UART so this is a trade-off. This could be the reason why microchip uses 'old code', but stable(?) code. An other approach would to have the same USB stack as source. By commenting out unneedded code it could be still light and benefit from bugfixes or newly introduces bugs ;) Sharing the stack with the maincode is not wise, when the main code is corrupted (suppose you are testing an new USB stack ;))

A disadvantage of the picplatform is that the interruptvectors are stored in flash and are thus inflexable. Dunno if usb connection is possible without interrupts (guess not). Moving the code to the end is a good idea (you protect the fuses).

Re: bootloaders

Reply #4
Moving the code to the end is a good idea (you protect the fuses).

Ah, but not all PICs are created equal ;) The 18F and under have config fuses in a 'special' memory location.

Interrupt is not needed for USB, you can poll or use interrupts. THe USB bootloader for the IR Toy and OLS uses polling and state machines (may use a wake-from-sleep interrupt though)
Got a question? Please ask in the forum for the fastest answers.

Re: bootloaders

Reply #5
[quote author="Sjaak"]An other approach would to have the same USB stack as source. By commenting out unneedded code it could be still light and benefit from bugfixes or newly introduces bugs ;) Sharing the stack with the maincode is not wise, when the main code is corrupted (suppose you are testing an new USB stack ;))[/quote]
All of your comments were welcome, but I wanted to respond to the item above.
My design placed the USB stack in the bootloader, so corrupted main code would not be an issue. The main code would use the USB stack in the bootloader via an indirect function jump table, with the option of overriding any or all functions as needed by improvements. Meanwhile, the bootloader calls the USB functions directly since the jump table is not needed internally. As I mentioned, the drawback is always that you cannot update the bootloader once it is in the field without programming hardware.

Re: bootloaders

Reply #6
[quote author="ian"]Ah, but not all PICs are created equal. The 18F and under have config fuses in a 'special' memory location.[/quote]
True, but the PIC18F87J50 Family has config in Flash. That's my favorite USB PIC. As you say, not all PICs are created equally!

Re: bootloaders

Reply #7
Yes, the PIC 18F24J60 in the OLS is the same family and it also has those config words. I really like these chip because they're somewhere between 18F and 24F.
Got a question? Please ask in the forum for the fastest answers.