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.

* 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?

(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:

#option org_reset = 0xF00

This relocates the microcontroller reset address and will generate the following ASM 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 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):

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

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.

Share this article