PIC18 USB Bootloaders

Microchip released a USB Bootloader which supports pretty much every device with USB (back in 2008 - I must be living under a rock). It can be downloaded on the Application Libraries page, read on before you do. The package includes the source code and a compiled program for the graphic user interface, screen shot below.

BL_SC* note - this is the full version of the GUI - I've included it in the download package *

The Microchip bootloader includes support for a development board (reset switch/LEDs) which typically isn’t needed for practical use. Joe Hanley (more commonly known as Captainslarty on the proton site) went one step further and removed the additional hardware support, and then packaged all of the precompiled firmware for popular PIC18 devices. At the time of writing, the USB bootloader firmware supports the 18F14K50, 18F2450, 18F2455, 18F2458, 18F2550, 18F2553, 18F4450, 18F4455, 18F4458, 18F4550 and 18F4553 (with 8 or 20Mhz crystal oscillators).

Thanks to Joe, the process of working with the USB Bootloader is simple:

  1. Download the PIC18 USB Bootloader pack (and unzip it).
  2. Flash the appropriate firmware to your device (using a PICKit 2, for example).
  3. The device can now be flashed with a USB cable and PC software.

Note you do not have to use MPLAB or have any knowledge of C18. Once the device is loaded you can flash the device with firmware written in any language. If you want to venture out of the precompiled configurations, then you'll need to get familiar with C18 and have a close look at the original Microchip code.

Why a USB Bootloader?

USB_Bootloader(click to enlarge)

Lets be honest, not everyone that is reading this will understand the significance behind a USB bootloader. Once the device has the bootloader firmware installed, an external programmer is not required. You can interface directily with the device via a USB cable (by comparison to the ds30 Loader which requires a serial interface). On the left is a diagram comparing a device with/without a bootloader.

With the bootloader installed, the device checks to see if it can communicate with the PC software. If it can, it will allow the PC software to control the device (read/write new firmware etc). If the PC software is not detected (for example, the device is disconnected), the program then enters the user application.

 

 

Lower ROM Bootloaders

I find that typically bootloaders are located in high ROM, which allows compilers to go about business as usual. The Microchip USB bootloader is located in lower ROM which means your user application must start further down. Most compilers offer a simple directive to make this possible. In Swordfish Basic it is carried out like so:

Code Relocation Option
#option org_reset = 0xF00

This relocates the microcontroller reset address and will generate the following ASM code:

Assembly Code
ORG 0xF00
GOTO SBCDSTD
ORG 0xF08
SBCDSTD

Joe has included an example in the bootloader package for Proton, and it should be much the same for other compilers.

 

Interfacing with USB

In the datasheet of any PIC that supports USB there should be an example schematic along with useful information. In most cases, the PIC will be configured something like this (image courtesy of Swordfish Basic):

USB_Schematic

USB connectors are available from almost any electronics distributor. Here's a Mouser search for Type A USB female through-hole connectors. Prices start at around 70 cents. Another popular USB connector is the Mini-B (5 Pin). Here are a few others just in case you're wondering (wiki image):

800px-Usb_connectors

Types of USB connectors left to right (ruler in centimeters):

• Micro-B plug
• Mini-B plug (8-pin)
• Mini-B plug (5-pin)
• Standard-A receptacle
• Standard-A plug
• Standard-B plug

 

A warning for distributors

By law you are required to use your own vender and product ID for USB. The VID and HID included with this release is for demonstration and personal use only. You could be prosecuted if you decide to use the demo VID and HID on a commercial product.

 

Requirements

  • A serial programmer such as the PICKit 2 (only needed once).
  • A USB cable, duh!
  • .Net Framework V4

At the time of writing the package did not include the source code. I have asked Joe if he could as it would be handy to have the configuration bits and other definitions easily accessible. For the mean time, all the end user has to go by are the file names which indicate the external oscillator speed. Personally I'd like to know what configuration bits are set (and arn't) - especially given the scope of use.


Posted: 6 years 6 months ago by Graham Mitchell #7521
Graham Mitchell's Avatar
Good loader, although I've had some issues with Swordfish programs. Likely due to configuration settings, hard to tell without the source code.

I've made a variant of the loader that works in a similar way, am adding some final touches to it and will make it available to all soon enough
Posted: 6 years 6 months ago by Jon G #7525
 Jon G's Avatar
NICE! This is also a GUI to what is normally a command line app, if memory serves and I haven't also been under a rock. Whenever I see a company release a utility that is used through command line, it strikes me as an after-thought.

I'm all for command line stuff believe me, I'm a big Linux guy, but still...
Posted: 6 years 6 months ago by jmessina #7526
jmessina's Avatar
My post about what happens when you remove the code to read an IO pin for the bootloader seems to have vanished, but I still have the same question.

If the bootloader always inits the USB stack and waits for a message at power up, how do you keep it from getting stuck at power on if you happen to be running an app that communicates to the device? In the Mchip version, if the pin isn't asserted then the bootloader just continues on and runs the app.

There's scant details, and no source to look at with Joe's solution. It's convenient not needing a pin, but how's it actually work?
Posted: 6 years 6 months ago by Graham Mitchell #7529
Graham Mitchell's Avatar
Sorry Jerry - I've unpublished the topic for a moment while I make a couple more changes. I believe this bootloader works in a similar way as I am with the RCON RI flag - upon a fresh power cycle the device is in "bootload" mode, and if the PC application is running then it will connect. If not, then it will run the user application.

In addition, if the PIC does detect the PC software, then the user can reset the device from the PC, removing it from "bootload" mode.
Posted: 6 years 6 months ago by jmessina #7530
jmessina's Avatar
So when it powers up, the bootloader runs, initializes the USB stack, and waits for a message? How long does it wait? What if it gets a USB message that isn't from the bootloader application?
Posted: 6 years 6 months ago by Graham Mitchell #7531
Graham Mitchell's Avatar
I hear you - there's not much to go by without the source code. It's early days for this take on the bootloader, Joe is considering going open source down the track - until then the best way to figure out what's going on under the hood is to contact him.
Posted: 6 years 6 months ago by jmessina #7532
jmessina's Avatar
It would just worry me if the loader runs at power on all by itself. The packet format is VERY simple, and all you need is a single packet that starts with $04 and you've now got an erased device.

I suppose you could use a special VID/PID combination, or a more robust packet format, but if the code's anything like the current Mchip loader I think I'd feel a lot better with having to push a button... maybe two.

Perhaps he's implemented some sort of special command/handshake to get the ball rolling. That might be a bit safer.
Posted: 6 years 6 months ago by Graham Mitchell #7533
Graham Mitchell's Avatar
I think I'd feel a lot better with having to push a button... maybe two
Gold

Perhaps in the near future we'll see some more documentation, or code
Posted: 6 years 6 months ago by Captainslarty #7537
Captainslarty's Avatar
Hi Graham,
You have to remember that the usb hid stack is ONLY used in the bootloader, not in your app, if you write a hid app, it will have it's own usb stack, you can add a cdc stack if you need it. There is no issue with another app calling the loader. If you program, for example, a cdc stack, plug the device into the pc, then without the programming app running, it will immediately enter the program cdc stack, not the hid loader, same with say a hid joystick, without the programming app running, it will immediately be seen as a hid joystick.
The only caveat is that the bootloader PID and your program that you write PID must be different as the loader pc side uses this info. Once can have the same VID though. I have indicated on the wiki for Proton that I will add custon VID and PID to the files for licensed PDS users. This is a service free to those uses in support of Crownhill and as a way of thanks to them. At some point later in the year I will consider releasing the source. In the mean time, if anyone needs something specific then please feel free to contact me.
You can change any config setting you need, or view them, by looking at the config fuse settings on the pickit gui app. included in the settings.txt is an example to alter the loader for any xtal speed you require.
If you then want to alter settings from within your application, you can click the allow config programming button, but you must obviously keep the xtal settings the same and the multiplyer, also adding code protection fuses etc would not be a good idea lol.
So the settings txt shows how to use any xtal frequency to end up with the 48Mhz internal clock, then anything else you want to change is possible. The only thing the user should ever need to change is the xtal frequency in the loader.. WDT etc can be easilly added at aplication programming time.
Hope that helps.?
Joe
Posted: 6 years 6 months ago by RangerBob #7538
RangerBob's Avatar
Good loader, although I've had some issues with Swordfish programs. Likely due to configuration settings, hard to tell without the source code.

I've made a variant of the loader that works in a similar way, am adding some final touches to it and will make it available to all soon enough

Interested to see your loader when it is ready too.

I've also found some issues with swordfish and the microchip HID bootloader a long while back. I originally traced it back to some register that gets touched by the bootloader and which swordfish expects to be at some other default value. Thats as far as I got.

As a work around, first thing I do with any program using HID bootloader is set all the registers back to their default value from the datasheet. Not ideal but works for me in a production environment.

Forum Activity

Member Access