The AYUCR Bootloader is a provides a simple interface for reading and writing the processor's flash program and data memory. It can be used to reprogram the processor's firmware using only the serial port interface without an external PIC programmer. This is ideal (and indeed, designed) for users to field update their electronics to fix bugs, add features or repurpose designs entirely.

The AYUCR bootloader (or simply bootloader) Provides a protocol for reading the entire PIC program address space, writing the non-bootloader or "user" portion of the address space and write the entire data address space. Using this protocol it is possible to implement a bootloader driver to read and reprogram the firmware as well as verify the results. It is designed to be relatively robust and error-proof while using less than 256 bytes of program memory and about 70 bytes of SRAM. This includes the bootloader interface, serial I/O routines and low-level flash read/write/erase routines.

In addition to field updates of firmware the bootloader provides features to allow for rapid software development. By using a special, 4-conductor serial cable that uses the DTR line to reset the processor the bootloader driver can reset the processor, send a break signal to trigger the bootloader, update the firmware and resest the process to run the new program. This makes the software development mach easier and far faster than using an external programmer. The same serial line can even be used for debugging output making the whole system similar to a Basic Stamp

Bootloader Startup

There are several ways to initiate the bootloader three of which are common.

Command Method
If you are using AYUCR electronics that implement a serial port command interface sending the "B" command will generally put the unit in bootloader mode. If successful the bootloader will echo the "K" prompt (meaning OK) and wait for a command. After that all commands are a single letter as described below. This is the method used by the AYUCR PC Interface

Hardware Method
For bench testing the hardware method is generally preferable. When used with a development firmware driver this allows the hardware to be reflashed and reset with minimal software support and without the firmware implementing a command mode. A call to boot_detect is required at the top of the firmware after the initialization routine to detect a request to enter the boot loader on reset. If boot_detect does not receive the signal it will simply return and initialization will proceed normally. There are also some hardware requirements:

AYUCR Bootloader Schematic

AYUCR Bootloader Schematic

/MCLR, RB0 and RB1 are pins 4, 6 and 7 on the PIC 16F819 respectively. The NPN transistor serves to invert and level convert the DTR line. When first opened the serial port DTR line is set high resetting the processor. Lower the DTR line will bring the processor out of reset.

The sequence of events that the driver initiates to start the bootloader in this configuration is as follows:

See Article on Bootloader Development Platform for a complete description of the BLoad development adapter and the BLoad bootloader driver

Firmware Method

Custom firmware may call the boot_loader routine directly in software to initiate the bootloader for custom configurations. This is not typical.

Bootloader Commands:

The bootloader itself is a simple command processor that expects and executes commanands transmitted over the serial port at either 2400 or 9600 baud depending on the version. One of several response codes are returned after each command is executed. All commands operate on pages of 64 bytes at a time. This translates into pages of 32 program words since each word is 16 bits (actually 14 but the two most significant bits are padding) each page is 64 bytes long. Data memory commands operate on 64 byte data pages. All commands are sent with an additional checksum byte for error checking.

Reads a page of flash program memory. The command is 4 bytes long, 1 byte for the command character 'R', two for the address and 1 checksum byte. This command returns [DATA] followed by [CHK] (65 bytes total)

Writes a page to flash program memory. The command is 68 bytes long, 1 byte for the command character 'W', two for the address, a 64 byte data frame and a checksum byte.

Erases a page of flash program memory. The command is 4 bytes long, 1 byte for the command character 'E', two for the address and 1 checksum byte.

Writes a page to flash data memory. The command is 68 bytes long, 1 byte for the command character 'D', two for the address, a 64 byte data frame and a checksum byte.

Exits the bootloader and resets the chip. This is not a hard reset and the contents of the data registers will not be reset. Effectively all that is happening is control is transfered to location 0x000 as on power up.


[ADR] - The address is two bytes long and is sent low byte first. The range of address (for the 16F819) is 0x0000 - 0x07FF for Read and 0x0020 - 0x06FF for Erase and Write. The difference is the bootloader will not allow you to overwrite it as this would produce strange results and migh break the firmware requiring a reflash using an external programmer.

[CHK] - A simple checksum of the databytes transmitted for error checking When appended to commands the checksum excludes the first command byte. The checksum for the read and erase commands applies to the 2 [ADR] bytes. The checksum for the write command applies to the 2 [ADR] and the 64 [DATA] bytes. The checksum returned after the 64 [DATA] bytes in the read command is calculated on those bytes.

[DATA] - represents an entire page of flash program memory. The page is organized as 32 low byte/high byte pairs.

Return Codes:

K - Ready to accept the next command
R - Address range error
C - Data checksum error

When a command completes successfully the 'K' prompt will be all that is sent. There is no success code. The absense of a R or C error code is enough to indicate success.

The processor will issue a range error (R) if write or erase command and the target address would overwrite the bootloader itself. Overwriting the bootloader region while the processor is executing the bootloader would probably cause weird behavior possibly rendering the chip unusable without reflashing from scratch in a dedicated programmer.

Notice there is no command to read from data memory. This is cause by limited program space to implement features. For updating firmware this is not really a problem. It does mean the data segment can't be verified after writes but this is far less critical than for writes to the program memory

The bootloader is designed to interface with a program which reads the firmware .HEX file and uses the bootloader to write the new firmware to the chip. I have written various bootloader drivers using this protocol in Perl and C#. They are available on the Software page and Bootloader Development Platform Article.

This takes a little while at 2400 baud, perhaps 30 seconds. Changes to the firmware that alter the bootloader, serial I/O or flash program memory routines require reflashing the chip externally as these routines all reside in the bootloader-safe region of memory.


The command to read the page starting at 0x0020 (the first user page) is:

0x52 0x20 0x00 0x20

Notice that the address is sent LSB first and that the checksum excludes the command byte (0x52 or 'R'). The bytes above are expressed in hex. The total command length is 4 bytes. The bootloader will return the page requested as 32 two byte words, low bytes first followed by a checksum byte and then the 'K' prompt/success code. If there was an error, perhaps a checksum error indicating a problem receiving the command, the return code would be C followed by K.

The command to erase a page starting at 0x06DF (the last user page) is:

0x45 0xDF 0x06 0xE5

The return code following the operation will be 'K' A return of C followed by K indicates a checksum error.

The command to (attempt) to erase the page starting at 0x0700 (the first bootloader page) is:

0x45 0x00 0x07 0x07

This command will return R followed by K to indicate that a range error occurred.