USB BootLoader

Documentation
1.Introduction
2.License
3.Bootloader compilation
4.Bootloader programming into the target PIC18F microcontroller
5.Bootloader Software
6.Functioning
7.GNU Free Documentation License
8.GNU General Public License version 3
9.PC and Bootloader Interaction Protocol
10.Setup and configuration
11.USB interface implementation
1.Introduction
This manual describes Bootloader for PIC18F4455 microcontroller, its compilation, usage and
customization.
Bootloader is a resident program, that resides in the lower 2048 bytes of the PIC microcontroller
flash memory. It can program the remaining memory without necessity to use any external
hardware (like ICD2 programmer). Bootloader receives data from PC through USB bus and writes
it into the PIC microcontroller memory.
Bootloaders utilizes the most common interfaced to communicate with PC. Some of them are RS-
232 and USB. It is only possible to use the particular interface when both PC and microcontroller
have it.
It contrast to most other bootloaders, PIC USB Bootloader doesn't require any HW changes in your
device. It uses the standard USB interface of PIC18F4455 microcontroller.
Bootloader utilizes memory self-programming ability of PIC18F4455 microcontrollers. Once

burned into the microcontroller flash memory, bootloader can repeatedly reprogram it without
expensive chip writers or ICSP (In-Circuit Serial Programmer).
XTEA encryption algorithm protects user mode application from unauthorized copying. The
encryption password together with the bootloader is burned into microcontroller flash memory
during device production. To update the user mode application, you can send the encrypted file to
customer. This application will only work fine on the devices containing the same bootloader with
the same password. Any attempt to install this program into device with another password will
result in complete inoperability. Bootloader itself and the password is protected by internal
microcontroller configuration bits. Nobody can read it from the microcontroller.
2.License
This manual is distributed under the terms of the GNU Free Documentation License.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.2 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of
the license is included in the section entitled Appendix A. GNU Free Documentation License.
Bootloader is distributed under the terms of the GNU General Public License version 3.
Bootloader is free software: you can redistribute it and/or modify it under the terms of the GNU
General Public License as published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version. This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
Public License for more details. You should have received a copy of the Appendix B. GNU General
Public License version 3 along with this program. If not, see http://www.gnu.org/licenses/.
3.Bootloader compilation
You can skip this chapter if you use a PIC USB Demo Board. The microcontroller on this demo
board already contains compiled and ready to use bootloader.
USB PIC Bootloader is distributed with its source code. The most recent version you can download
from the Diolan website. The distribution contains all the necessary MPLAB project files.
Bootloader is developed on PIC18 assembler language. MPASM compiler is all you need to
compile it. At the time of writing this documentation MPASM compiler is free and can be
downloaded from Microchip company website. MPASM is also part of an integrated development
environment MPLAB. Further description of the compilation process implies the use of MPLAB.
To compile the bootloader you will need:
Bootloader - source code of the program, which you can download from the Diolan company web site;
MPLAB - integrated development environment for PIC microcontrollers;
MPASM - assembler for PIC18 microcontrollers.
Download the file with bootloader source code and unzip it. To unpack the archive you can use
WinZIP, WinRAR or any other ZIP format archiver. If you use OS Windows XP, you can use the
built-in unpacker. To do this, click right mouse button over the archive file and select "Extract"
from the menu. As a result, you will get pic_bootloader folder, containing Diolan USB PIC
Bootloader source code.
Use MPLAB to compile bootloader source code. If you do not have MPLAB, you can download it
from Microchip web site and install. MPLAB has its own documentation for installation and usage.
We encourage you to read this documentation before compiling the bootloader source code. During
the installation you have to choose support for 8 bit PIC18 microcontrollers and MPASM Suite.
Start MPLAB and open the bootloader project with "File->Open Workspace" menu. To do this in
the file open window go to the directory containing the unpacked bootloader and choose the
bootloader.mcw file. You will see a list of bootloader source code files in the project window.
Bootloader uses its own linker command file - Bootloader.lkr. Verify that this file is specified in the
list of project files. Verify the configuration options to specify your type of the microcontroller. To
select the microcontroller type, use "Configuration->Select Device" menu and select PIC18F4455.
Then, using the menu "Configure->Configuration Bits" open the window with the configuration bits
and select checkbox "Configuration Bits set in code".
Open the project settings dialog using the menu "Project->Build options->Project", select
Microchip MPLAB Suite tab and verify that the check box marked "Extended mode" is on.
Bootloader has to be compiled in PIC18 advanced mode. See microcontroller documentation for
detailed information on different operation modes.
Use the menu "Project->Build" or click the Build button on the toolbar to start the compilation.
After the compilation bootloader can be programmed into the target microcontroller.
4.Bootloader programming into the target PIC18F

microcontroller
You can skip this chapter if you use a PIC USB Demo Board as the microprocessor for this
demonstration board already has compiled and programmed bootloader.
You would need a chip writer to program the Bootloader into the target microcontroller. There are
many different chip writers for PIC18F. This manual describes the using of Microchip ICD2
programmer.
After a successful compilation you can program the bootloader into the target microcontroller.
Make sure that ICD2 drivers are installed, and it is connected to the PC.
Verify that the ICD2 is not used as a debugger. To do this select "None" in the "Debug->Select"
menu, and select "ICD2" in the "Programmer->Select" menu. You will see a ICD2 programmer
toolbar.
Open the ICD2 programmer properties window using the "Programmer->Settings" menu. If ICD2 is
connected to the USB port of your PC, select "USB" at the "Interface" tab. If you connected ICD2
to COM port, choose the appropriate COM port and speed. Click "OK" button to close the dialog.
Connect ICD2 to the target microcontroller. Click "Connect ICD2" button. If ICD2 is correctly
connected to the target microcontroller, you will see the microcontroller type and revision number
in MPLAB messages window. Verify that the information corresponds to the selected
microcontroller in MPLAB configuration settings.
In case of errors, make sure that the ICD2 is connected to a USB port, ICD2 driver installed, ICD2
is connected to target microcontroller, connection cords are in good order, and power is supplied to
both ICD2 and microcontroller.
Click the "Program" button on the ICD2 toolbar. Wait for programming completion and disconnect
the target microcontroller from ICD2.
5.Bootloader Software
Encoder Application
Fw_update Application
Introduction
Linux Features
5.1.Encoder Application
The encoder application allows to encript or decript HEX files for microcontroller. The encription is
implemented by using XTEA algorithm. You can also browse the recent source code online at
"encoder source code".
The encoder application supports the following commands (Table 8.1, Encoder commands):
Table 8.1. Encoder commands
Short Full Parameter

Description
Command Command Value
-h -help Displays the supported commands and options description.
Encode the input file with PASSWORD and save it to output file.
-e -encode PASSWORD PASSWORD is used as an encryption key. PASSWORD has to be
provided as string of two hex digits per byte (like 01202040ac).
Decode the input file with PASSWORD and save it to output file.
-d -decode PASSWORD PASSWORD is used as an encryption key. PASSWORD has to be
provided as string of two hex digits per byte (like 01202040ac).
-c -convert Convert the file from one format to another.
The encoder application supports the following options(Table 8.2, Encoder options):
Table 8.2. Encoder options
Short Parameter
Full Option Description
Option Value
-ix -input_hex FILENAME Input file in Intel Hex Format.
-ib -input_bin FILENAME Input file in Binary Format.
-id -input_data DATA Immediate mode - actual byte(s) specified in the command line as
Short Parameter
Option Value
string of two hex digits per byte (like 01202040ac).
-
-ox FILENAME Output file in Intel Hex Format.
output_hex
-ob -output_bin FILENAME Output file in Binary Format.
For instance, we need to perform the "example.hex" file encryption using Intel Hex file format and
"0102030405060708090a0b0c0d0e0f10" encription key. The command line for this operation is:
encoder -e 0102030405060708090a0b0c0d0e0f10
-ix example.hex -ox example_encrypted.hex
To decrypt "example_encrypted.hex" use following command line:
encoder -d 0102030405060708090a0b0c0d0e0f10
-ix example_encrypted.hex -ox example_decrypted.hex
5.2.Fw_update Application
The fw_update application allows you to update microcontroller firmware. To update
microcontroller's firmware you should switch your microcontroller to firmware mode and connect it
to USB. The fw_update application supports the following commands(Table 8.3, Fw_update
commands):
Table 8.3. Fw_update commands
Short Command Full Command Description
-w -write Write data to device.
-r -read Read data from device.
-v -verify Verify device memory.
-e -erase Erase device memory.
-ver -version Display versions of fw_update and Bootloader if present.
-h -help Displays the supported commands and options description.

The fw_update application supports the following options(Table 8.4, Fw_update options):
Table 8.4. Fw_update options
Short Parameter
Option Value
MEMORY Memory type for read, write and verify operations. Possible values:
-m -memory
TYPE flash, eeprom, id, all. Default: flash.
-vid -vendorid VID Device vendor ID.
-pid -productid PID Device product ID.
-t -reset YES | NO Reset device after operation is finished. Default: YES
-s -size SIZE The data size for read, write and verify operations.
The start address for read, write and verify operations. Default:
-a -address ADDR
0x800 for flash, 0x00 for other memory types.
-ix -image_hex_in FILENAME Image file in Intel Hex Format for write and verify operations.
-ib -image_bin_in FILENAME Image file in Binary Format for write and verify operations.
-
-ox FILENAME Image file in Intel Hex Format for read operation to save data.
image_hex_out
-
-ob FILENAME Image file in Binary Format for read operation to save data.
image_bin_out
Immediate mode - actual byte(s) specified in the command line. Data

for write and verify operations must be provided as string of two hex
-d -data DATA
digits per byte (like 01202040ac). For read operation data is printed
on screen.
For instanse, we need to perform microcontroller firmware update. The command line for such
operation is:
fw_update -e -w -v -vid 0x04D8 -pid 0xFF04 -ix example_encrypted.hex
5.3.Introduction
Bootloader software contains the following applications: encoder and fw_update. Both applications run under console. You
can run bootloader software under Windows 2000/XP/NT/98, Linux, FreeBSD, Darwing, Mac Operating Systems.
Encoder and fw_update applications are distributed with open source code.
6.Functioning
Bootloader is a program for PIC18F4455. It can be used with other microcontrollers, if they have
USB interface compatible with PIC18F4455. The necessary changes are described in Chapter 5.
Setup and configuration.
Bootloader allows you to burn other programs into the microcontroller flash memory and run them.
Bootloader is located in the lower 2048 bytes of PIC microcontroller Flash memory and uses its
reset and interrupt vectors. This imposes some limitations on the user application, and requires
additional changes in the source code.
To work with Bootloader, user mode application must be linked using a special command file for
MPLINK. The necessary linker command files can be found in the bootloader installation package.
The user mode program should begin with the address 0x0800, because the zero address is occupied
by the bootloader. Bootloader automatically passes control to the address 0x0800 to start the user
mode program.
If the user mode application uses interrupts, the interrupt vectors also must be redefined:
high priority interrupts vector must be located at address 0x0808;

low priority interrupts vector must be located at address 0x0818.
Example for MCC18:
#pragma code high_vector=0x0808

void interrupt_at_high_vector(void)
{
}
#pragma code low_vector=0x0818
void interrupt_at_low_vector(void)
{
}
Example for MPASM:
ORG 0x0808
interrupt_at_high_vector
goto high_int_handler
ORG 0x0818
interrupt_at_low_vector
goto low_int_handler
9.PC and Bootloader Interaction Protocol

Bootloader API
Bootloader Commands
Bootloader Responses
Header Files
9.1.Bootloader API
Bootloader supports reading, erasing and writing PIC microcontroller Flash and EEPROM
memories and ID locations. We provide fw_update application that interacts with bootloader.
However the need for customized programs development can appear. This Chapter describes
Bootloader and PC software interaction protocol.
9.2.Bootloader Commands
BOOT_ERASE_FLASH command
BOOT_GET_FW_VER command
BOOT_READ_EEPROM command
BOOT_READ_FLASH command
BOOT_READ_ID command
BOOT_RESET command
BOOT_WRITE_EEPROM command
BOOT_WRITE_FLASH command
BOOT_WRITE_ID command
Boot_cmd union
9.2.1.BOOT_ERASE_FLASH command
BOOT_ERASE_FLASH command is used to erase flash memory.
Before sending BOOT_ERASE_FLASH command you have to fill in boot_cmd_erase_flash

structure:
typedef struct
{
unsigned char cmd; /* command code, see BOOT_xxx constants */
unsigned char echo; /* echo is used to link between command and response */
unsigned char addr_lo; /* address must be divisible by 64 */
unsigned char addr_hi;
unsigned char reserved[1];
unsigned char size_x64; /* size in 64 byte blocks */
} boot_cmd_erase_flash;
Fields assignment:
cmd
Command code; the given field must be initialized by BOOT_ERASE_FLASH constant

value.
echo
Package ID. Its value is selected arbitrarily before the command is sent. In the simplest case
it is a counter value, increased by one while sending every new command. Bootloader does
not analyze this field value. It simply copies it into response. Therefore, when response
received, PC program can connect this response to previously sent command.
addr_lo
LSB byte of the address, from which flash memory erase starts. As the minimum erase block
is 64 bytes, addr_lo parameter value must be divisible by 64.
addr_hi
MSB byte of the address, from which flash memory erase starts.
reserved
Not used.
size_x64
The number of 64-bytes blocks to erase. As programs memory in PIC18 microcontrollers is

erased by blocks of 64 bytes, this parameter sets the number of 64 bytes blocks.
After this command is processed, Bootloader sends response with code BOOT_ERASE_FLASH.
9.2.2.BOOT_GET_FW_VER command
BOOT_GET_FW_VER command is used to determine Bootloader version.
Before you send this command you have to fill in boot_cmd_get_fw_ver structure:
typedef struct
{
} boot_cmd_get_fw_ver;
Fields assignment:
cmd
Command code; the given field must be initialized by BOOT_GET_FW_VER constant

value.
echo
After this command is processed, Bootloader sends response with code BOOT_GET_FW_VER.
9.2.3.BOOT_READ_EEPROM command
BOOT_READ_EEPROM command is used to read data block from microcontroller EEPROM
memory.
Before you send the given command you have to fill in boot_cmd_read_eeprom structure:
typedef struct
{
unsigned char addr; /* EEPROM address to start read from */
unsigned char size; /* size of EEPROM data to read */
} boot_cmd_read_eeprom;
Fields assignment:
cmd
Command code; the given field must be initialized by BOOT_WRITE_ID constant value.
echo
addr
The address from which flash memory read starts.
size
Flash memory size to read.
After this command is processed, Bootloader sends response with code BOOT_READ_EEPROM.
9.2.4.BOOT_READ_FLASH command
BOOT_READ_FLASH command is used to read data block from microcontrollers flash memory.
Before you send this command you have to fill in boot_cmd_read_flash structure:
typedef struct
{
unsigned char size8; /* size must be divisible by 8 */
} boot_cmd_read_flash;
Commands description:
cmd
Command code; the given field must be initialized by BOOT_READ_FLASH constant value.
echo
addr_lo
LSB byte of the address, from which flash memory read starts. As flash memory is
organized to store data as words, addr_lo parameter value must be odd aligned with 16-
bit word boundary.
addr_hi
MSB byte of the address, from which flash memory read starts.
reserved
Not used.
size8
Flash memory size to read. The size specifies the number of bytes to read and must be
divisible by 8.
After this command is processed, Bootloader sends response with code BOOT_READ_FLASH.
9.2.5.BOOT_READ_ID command
BOOT_READ_ID command is used to read the content of ID Locations of PIC microcontroller.
ID Locations are eight memory locations of PIC memory microcontroller (200000h-200007h).

They can be used to store checksum or other code identification numbers.
Before sending BOOT_READ_ID command you have to fill in boot_cmd_read_id structure:
typedef struct
{
} boot_cmd_read_id;
Fields assignment:
cmd
Command code; the given field must be initialized by BOOT_READ_ID constant value.
echo
After this command is processed, Bootloader sends response with BOOT_READ_ID code.
9.2.6.BOOT_RESET command
BOOT_RESET command switches bootloader into user mode. It must be sent only after user
application is written and verified for correctness. After receiving BOOT_RESET command
Bootloader clears EEPROM mark (see the section called EEPROM Mark configuration
(EEPROM Mark)) and resets the microcontroller. After reset control is passed to user mode
application. If user-mode application was not written or was written with errors the result may be
unpredictable. In this case you have to use the jumper (see the section called Jumper
configuration) to switch Bootloader into programming mode.
Bootloader does not send response to BOOT_RESET command. It disconnects the device from
USB bus and PC application stops receiving responses from Bootloader. It can't send commands
any more either.
Before sending BOOT_RESET command you have to fill in boot_cmd_reset structure:
typedef struct
{
} boot_cmd_reset;
Fields assignment:
cmd
Command code; the given field must be initialized by BOOT_RESET constant value.
9.2.7.BOOT_WRITE_EEPROM command
BOOT_WRITE_EEPROM command is used to write data into microcontroller EEPROM
memory.
Before sending the given command you have to fill in boot_cmd_write_eeprom structure:
typedef struct
{
unsigned char addr; /* EEPROM address to start write to */
unsigned char size; /* size of EEPROM data to write */
unsigned char data[BOOT_CMD_SIZE - 6];
} boot_cmd_write_eeprom;
Fields assignment:
cmd
Command code; the given field must be initialized by BOOT_WRITE_EEPROM constant

value.
echo
addr
The address from which EEPROM memory write starts.
size
The size of the data block to write (in bytes).
echo
Data to be written into the microcontroller EERPOM memory.
After this command is processed, Bootloader sends response with code BOOT_WRITE_EEPROM.
9.2.8.BOOT_WRITE_FLASH command
BOOT_WRITE_FLASH command is used to write data into flash memory.
Before writing, flash memory must be erased by BOOT_ERASE_FLASH command.
Bootloader does not verify written data while processing BOOT_WRITE_FLASH command. You
can use BOOT_READ_FLASH command for reading and further verification of the data.
If XTEA encryption algorithm is used (see the section called XTEA - The encryption key), the
command must contain the encrypted data. The encryption can be performed with encoder
application, which is included into the bootloader installation package. During encryption you have
to use the password, identical to the password in Bootloader.
Before sending this command you have to fill in boot_cmd_write_flash structure:
typedef struct
{
unsigned char cmd;
unsigned char echo;
unsigned char addr_lo;
unsigned char size8;
unsigned char data[BOOT_CMD_SIZE - 6];
} boot_cmd_write_flash;
Fields assignment:
cmd
Command code; the given field must be initialized by BOOT_WRITE_FLASH constant

value.
echo
addr_lo
LSB byte of the address, from which flash memory write starts. As flash memory is
organized to store data as words, addr_lo parameter value must be odd aligned with 16-bit
word boundary.
addr_hi
MSB byte of the address, from which flash memory write starts.
reserved
Not used.
size8
The size of the data block to be written. The size specifies the number of bytes to write and
must be divisible by 8.
data
Data to write.
After this command is processed, Bootloader sends response with code BOOT_WRITE_FLASH.
9.2.9.BOOT_WRITE_ID command
BOOT_WRITE_ID command is used to write data into ID Locations of PIC microcontroller.
Eight memory locations (200000h-200007h) are designated as ID locations, where the you can store
checksum or other code identification numbers.
Before sending the given command you have to fill in boot_cmd_write_id structure:
Fields assignment:
cmd
Command code; the given field must be initialized by BOOT_WRITE_ID constant value.
echo
reserved
Not used
data
Data to be written into the PIC microcontroller ID locations.
After this command is processed, Bootloader sends response with code BOOT_WRITE_ID.
9.2.10.Boot_cmd union
To ease software development, all commands, sent to Bootloader, are defined as structures.
As interface between PC and Bootloader supports only packages of fixed size, all structures are
members of boot_cmd union:
typedef union
{
/*
* data field is used to make all commands the same length
*/
unsigned char data[BOOT_CMD_SIZE];
boot_cmd_header header;
boot_cmd_read_flash read_flash;
boot_cmd_write_flash write_flash;
boot_cmd_erase_flash erase_flash;
boot_cmd_get_fw_ver get_fw_ver;
boot_cmd_reset reset;
boot_cmd_read_id read_id;
boot_cmd_write_id write_id;
boot_cmd_read_eeprom read_eeprom;
boot_cmd_write_eeprom write_eeprom;
} boot_cmd;
Fields assignment:
data
data field is added to make the size of all packages equal to BOOT_CMD_SIZE bytes.
header
header field is used to access general for all packages parameters - cmd echo. These
parameters are also available from other structures that define specific commands
parameters.
All other fields are used to access the parameters specific for the corresponding commands.
9.3.Bootloader Responses
BOOT_ERASE_FLASH response
BOOT_GET_FW_VER response
BOOT_READ_EEPROM response
BOOT_READ_FLASH response
BOOT_READ_ID response
BOOT_WRITE_EEPROM response
BOOT_WRITE_FLASH response
BOOT_WRITE_ID response
Boot_rsp union
9.3.1.BOOT_ERASE_FLASH response
Bootloader sends this response after BOOT_ERASE_FLASH command processing.
To ease data processing boot_rsp_erase_flash structure can be used:
typedef struct
{
} boot_rsp_erase_flash;
Fields assignment:
cmd
Command code. cmd field contains BOOT_ERASE_FLASH constant value for the given
response.
echo
Package ID. Bootloader copies it from the corresponding command before the response is
sent. Therefore, when response is received, PC program can associate this response with
previously sent command.
9.3.2.BOOT_GET_FW_VER response
Bootloader sends this response after BOOT_GET_FW_VER command processing. The response
contains Bootloader version number.
To ease data processing boot_rsp_get_fw_ver structure can be used:
typedef struct
{
unsigned char major;
unsigned char minor;
unsigned char sub_minor;
} boot_rsp_get_fw_ver;
Fields assignment:
cmd
Command code. cmd field contains BOOT_GET_FW_VER constant value for the given
response.
echo
major
Major version number.
minor
Minor version number.
sub_minor
Sub minor version number.
9.3.3.BOOT_READ_EEPROM response
Bootloader sends this response after BOOT_READ_EEPROM command processing. The response
contains data read from EEPROM memory.
If XTEA encryption algorithm is used (see "the section called XTEA - The encryption key"), the
response contains the encrypted data. It can be decrypted with encoder program, which comes with
Bootloader installation. During decryption you have to use the password, identical to the password
in Bootloader.
To ease data processing boot_rsp_read_eeprom structure can be used:
typedef struct
{
unsigned char addr; /* EEPROM address the data was read from*/
unsigned char size; /* size of EEPROM data */
unsigned char data[BOOT_RSP_SIZE - 6];
} boot_rsp_read_eeprom;
Fields assignment:
cmd
Command code. cmd field contains BOOT_READ_EEPROM constant value for the given
response.
echo
addr
The address, EEPROM memory reading starts from.
size
The size of the read data in bytes.
data
Data read from EEPROM memory.
9.3.4.BOOT_READ_FLASH response
Bootloader sends this response after BOOT_READ_FLASH command processing. The response
contains block of data, read from microcontroller flash memory.
If XTEA encryption algorithm is used (see the section called XTEA - The encryption key), the
response contains the encrypted data. This data can be decrypted with encoder application, which is
part of Bootloader setup package. During decryption you have to use the password, identical to the
password in Bootloader.
To ease data processing boot_rsp_read_flash structure can be used:
typedef struct
{
unsigned char size8; /* size must be divisible by 8*/
unsigned char data[BOOT_RSP_SIZE - 6];
} boot_rsp_read_flash;
Fields assignment:
cmd
Data field is used to make the size of all packages equal to BOOT_RSP_SIZE bytes.
echo
Header field is used to access common for all packages parameters - cmd and echo. These
parameters are also available from the structures that define specific responses.
addr_lo
LSB byte of the address, flash memory reading starts from.

addr_hi
MSB byte of the address, flash memory reading starts from.
reserved
Not used
size8
The size of the data in bytes.
data
Data read from microcontroller flash memory.
9.3.5.BOOT_READ_ID response
Bootloader sends this response after BOOT_READ_ID command processing. The response
contains data stored in ID Locations of PIC18F microcontroller.
Eight memory locations (200000h-200007h) are designated as ID locations, where the user can
store checksum or other code identification numbers.
To ease data processing boot_rsp_read_id structure can be used:
typedef struct
{
unsigned char data[BOOT_ID_LEN];
} boot_rsp_read_id;
Fields assignment:
cmd
Command code. cmd field contains BOOT_GET_FW_VER constant value for the given
response.
echo
reserved
Major version number.
data
Minor version number.
9.3.6.BOOT_WRITE_EEPROM response
Bootloader sends this response after BOOT_WRITE_EEPROM command processing. Bootloader
does not verify the written data while processing BOOT_WRITE_EEPROM command. You can
use BOOT_READ_EEPROM command for reading and further verification of the written data.
To ease data processing boot_rsp_write_eeprom structure can be used:
typedef struct
{
} boot_rsp_write_eeprom;
Fields assignment:
cmd
Command code. Cmd field contains BOOT_WRITE_EEPROM constant value for the given
response.
echo
9.3.7.BOOT_WRITE_FLASH response
Bootloader sends this response after BOOT_WRITE_FLASH command processing.
Bootloader does not verify the written data during processing BOOT_WRITE_FLASH command.
You can use BOOT_READ_FLASH command for reading and further verification of the written
data.
To ease data processing boot_rsp_write_flash structure can be used:
typedef struct
{
} boot_rsp_write_flash;
Fields assignment:
cmd
Command code. cmd field contains BOOT_WRITE_FLASH constant value.
echo
9.3.8.BOOT_WRITE_ID response
Bootloader sends this response after BOOT_WRITE_ID command processing.
Bootloader does not verify the written data while performing BOOT_WRITE_ID command. You
can use BOOT_READ_ID command for reading and further verification of written data.
To ease data processing boot_rsp_write_id structure can be used:
typedef struct
{
} boot_rsp_write_flash;
Fields assignment:
cmd
Command code. cmd field contains BOOT_WRITE_FLASH constant value.
echo
9.3.9.Boot_rsp union
To ease software development, all bootloader responses are described as structures.
As interface between PC and Bootloader supports only packages of fixed size, all structures are
boot_rsp union members:
typedef union
{
/*
* data field is used to make all responses the same length
*/
unsigned char data[BOOT_RSP_SIZE];
boot_rsp_header header;
boot_rsp_read_flash read_flash;
boot_rsp_write_flash write_flash;
boot_rsp_erase_flash erase_flash;
boot_rsp_fw_ver get_fw_ver;
boot_rsp_read_id read_id;
boot_rsp_write_id write_id;
boot_rsp_read_eeprom read_eeprom;
boot_rsp_write_eeprom write_eeprom;
} boot_rsp;
Fields assignment:
data
Data field is used to make the size of all packages equal to BOOT_RSP_SIZE bytes.
header
All other fields are used to access the particular response parameters.
9.4.Header Files
To ease PC software development Bootloader source code contains boot_if.h file. This file is not
used by Bootloader itself. It defines Bootloader and PC software interaction protocol in C
programming language.
It is strongly recommended not to modify this file! Any modifications of data structure, commands,
constants etc. can lead to interface change and to unpredictable behavior!
The boot_if.h file defines commands sent by PC program to bootloader. Bootloader supports the
following commands:
#define BOOT_READ_FLASH 0x01

#define BOOT_WRITE_FLASH 0x02
#define BOOT_ERASE_FLASH 0x03
#define BOOT_GET_FW_VER 0x04
#define BOOT_RESET 0x05
#define BOOT_READ_ID 0x06
#define BOOT_WRITE_ID 0x07
#define BOOT_READ_EEPROM 0x08
#define BOOT_WRITE_EEPROM 0x09
#define BOOT_CMD_UNKNOWN 0xFF
Commands description:
BOOT_READ_FLASH
On receipt of this command bootloader reads and transfers to PC requested part of flash
memory.
BOOT_WRITE_FLASH
On receipt of this command bootloader writes data received from PC into the
microcontroller flash memory.
BOOT_ERASE_FLASH
On receipt of this command bootloader erases requested part of flash memory.
BOOT_GET_FW_VER
On receipt of this command bootloader sends back its version number.
BOOT_RESET
On receipt of this command bootloader clears EEPROM mark, resets the microcontroller
and enters user mode (launching user mode application).
BOOT_READ_ID
On receipt of this command bootloader reads and sends back to PC the content of PIC
microcontroller ID locations. Eight memory locations (200000h-200007h) are designated as
ID locations, where the user can store checksum or other code identification numbers.
BOOT_WRITE_ID
On receipt of this command bootloader writes data sent by host into the microcontroller ID
locations.
BOOT_READ_EEPROM
On receipt of this command bootloader reads and transfers to PC requested part of

microcontroller EEPROM memory.
BOOT_WRITE_EEPROM
On receipt of this command bootloader writes data sent by host into the microcontroller
EEPROM memory.
BOOT_CMD_UNKNOWN
Unknown command. PC program must not send this program. Bootloader sets this code in
response, if it fails to identify the received command.
All interaction between Bootloader and PC program is based on sending and receiving data
packages of fixed length. The size of these packages is also defined in boot_if.h file:
#define BOOT_CMD_SIZE 64
#if( defined HID_OUT_EP_SIZE && (HID_OUT_EP_SIZE<BOOT_CMD_SIZE) )
#error "HID_OUT and CMD size mismatch HID_OUT_EP_SIZE<BOOT_CMD_SIZE"
#endif
#define BOOT_REP_SIZE 64
#if( defined HID_IN_EP_SIZE && (HID_IN_EP_SIZE<BOOT_CMD_SIZE) )
#error "HID_IN and CMD size mismatch HID_IN_EP_SIZE<BOOT_REP_SIZE"
#endif
No matter how much data command or response contains, package length must always be equal to
64 bytes. If there are less data it is located at the beginning of the package. The rest of the package
is simply ignored.
10.Setup and configuration

Introduction
Bootloader Configuration
CONFIG Registers - Code Protection
EEPROM Mark configuration
Jumper configuration
LED configuration
USB Module - Vendor ID and Product ID
XTEA - The Encryption Key
10.1.Introduction
This chapter describes the changes to be made in the bootloader source code to redefine its
parameters. They are intended to setup bootloader functionality and specify USB Vendor ID, USB
Product ID and XTEA key.
10.2.Bootloader Configuration
To configure bootloader you have to define macros for LED, jumper and EEPROM mark. Detailed
information about these marcoses can be found in the following sections.
Bootloader can run in 2 different modes:
firmware update mode;
In this mode, the device is recognized by computer as a standard HID device and user mode
application can be reprogrammed;
user mode;
In this mode, the management is passed to user mode application and the interrupt vectors are
redirected to the user mode application interrupt vectors.
The mode is determined in the main subroutine:
global main
main
UD_INIT
UD_TX 'X'
; Decide what to run bootloader or application
#if USE_EEPROM_MARK
; Check EEPROM mark
movlw EEPROM_MARK_ADDR
movwf EEADR
movlw 0x01
movwf EECON1
movlw EEPROM_MARK
subwf EEDATA, W
bz bootloader
#endif
; Check bootloader enable jumper
#ifdef USE_JP_BOOTLOADER_EN
setf JP_BOOTLOADER_TRIS
btfsc JP_BOOTLOADER_PORT, JP_BOOTLOADER_PIN
goto APP_RESET_VECTOR ; Run Application FW
#endif
; Run bootloader
bra bootloader
reset
As you can see from the source code, bootloader first checks the EEPROM mark. If mark is present,
bootloader starts in firmware update mode. For additional information about the EEPROM mark see
the section called "EPROM Mark configuration (EEPROM Mark)".
If EEPROM mark is absent, bootloader checks the jumper. If jumper is closed, bootloader starts in
firmware update mode. If jumper is opened, bootloader starts in user mode and control is passed to
user mode application. For additional information about jumper configuration see the section called
"Jumper configuration (jumper)".
10.3.CONFIG Registers - Code Protection

To prevent user application from unauthorized copying and to promote Bootloader fine
performance it is recommended to set the following values of CONFIG registers. They enable the
bootloader to perform all necessary operations with Flash memory, while denying access to external
tools, e.g., programmers.
Table 5.1. Recommended CONFIG registers values
Register Value Description Status

0x300006.bit7 1 Background Debug Disabled
0x300008 0x08 Code Protect 0x0800-0x1FFF Enabled
Code Protect 0x2000-0x3FFF Enabled
Code Protect 0x4000-0x5FFF Enabled
0x300009 0x80 Data EE Read Protect Disabled
Code Protect Boot Enabled
0x30000A 0x0F Table Write Protect 0x0800-0x1FFF Disabled
Table Write Protect 0x2000-0x3FFF Disabled
Table Write Protect 0x4000-0x5FFF Disabled
0x30000B 0x80 Data EE Write Protect Disabled
Table Write Protect Boot Enabled
Config Write Protect Enabled
0x30000C 0x0F Table Read Protect 0x0800-0x1FFF Disabled
Table Read Protect 0x2000-0x3FFF Disabled
Table Read Protect 0x4000-0x5FFF Disabled
0x30000D 0x00 Table Read Protect Boot Enabled
In Bootloader code CONFIG registers are set in boot.asm file as following:
CONFIG PLLDIV = 4 ; OSC/4 for 16MHz
CONFIG CPUDIV = OSC1_PLL2 ; CPU_clk = PLL/2
CONFIG USBDIV = 2 ; USB_clk = PLL/2

CONFIG FOSC = HSPLL_HS ; HS osc PLL
CONFIG FCMEN = ON ; Fail Safe Clock Monitor
CONFIG IESO = OFF ; Int/Ext switchover mode
CONFIG PWRT = ON ; PowerUp Timer
CONFIG BOR = OFF ; Brown Out
CONFIG VREGEN = ON ; Int Voltage Regulator
CONFIG WDT = OFF ; WatchDog Timer
CONFIG MCLRE = ON ; MCLR
CONFIG LPT1OSC = OFF ; Low Power OSC
CONFIG PBADEN = ON ; PORTB<4:0> A/D
CONFIG CCP2MX = ON ; CCP2 Mux RC1
CONFIG STVREN = ON ; Stack Overflow Reset
CONFIG LVP = OFF ; Low Voltage Programming
CONFIG ICPRT = OFF ; ICP
CONFIG XINST = ON ; Ext CPU Instruction Set
CONFIG DEBUG = OFF ; Background Debugging
CONFIG CP0 = ON ; Code Protect
CONFIG CP1 = ON
CONFIG CP2 = ON
CONFIG CPB = ON ; Boot Sect Code Protect
CONFIG CPD = OFF ; EEPROM Data Protect
CONFIG WRT0 = OFF ; Table Write Protect
CONFIG WRT1 = OFF
CONFIG WRT2 = OFF
CONFIG WRTB = ON ; Boot Table Write Protest
CONFIG WRTC = ON ; CONFIG Write Protect
CONFIG WRTD = OFF ; EEPROM Write Protect
CONFIG EBTR0 = OFF ; Ext Table Read Protect
CONFIG EBTR1 = OFF
CONFIG EBTR2 = OFF
CONFIG EBTRB = ON ; Boot Table Read Protect
10.4.EEPROM Mark configuration

EEPROM mark is used to guarantee fail-safe user mode application update. Bootloader sets mark in
EEPROM memory at receiving of the first command from host and removes it during reset
command (after the programming is completed). At the moment of user application programming
the mark is always set. If any errors occur (e.g., power drop or off), EEPROM mark remains. At the
next switch-on bootloader sees the EEPROM mark and enters the programming mode
automatically. User application can be reprogrammed. Only in case host completes application
upload and sends BOOT_RESET command, bootloader will clear EEPROM mark and run user
application.
EEPROM mark can also be used for soft entry into the programming mode. All user-mode
application has to do is to jump to 0x0016 address:
goto 0x0016
Bootloader will set EEPROM mark and reset the microcontroller to enter the programming mode.
EEPROM mark use is configured in boot.inc file with USE_EEPROM_MARK macro.
To use EEPROM mark macros value must be set to 1.
#define USE_EEPROM_MARK 1
If EEPROM mark is not used macros value must be set to 0.
#define USE_EEPROM_MARK 0
By default mark is located at address 0x00 of EEPROM memory. Bootloader enters the
programming mode, if it reads 0x5A or 0xF0 at this address. 0xF0 value is used for fail-safe user
mode application update. Bootloader doesnt change this value unless it receives BOOT_RESET
command from host. 0x5A value is used for soft reset. Bootloader resets this value (writes 0xFF
instead of it) when it enters the programming mode.
If necessary to change mark address or values, override the following macros:
in EEPROM_MARK_ADDR macro specify EEPROM memory address to place the mark;

in EEPROM_MARK macro specify the value for fail-safe update mark;
in EEPROM_MARK_SOFT_RESET macro specify the value for soft-reset mark;
These macros are defined in boot.inc file as shown below:
After EEPROM erase all bytes values are equal to 0xFF, therefore, it is better to use other values for
marks. If you use bootloader to program the microcontroller EEPROM memory, put the EEPROM
mark into the image file. Otherwise if any errors occur bootloader will enter the user mode and
launch the corrupted application.
10.5.Jumper configuration
Jumper is used for hardware entry into the programming mode. It connects the corresponding
microcontroller pin to ground (GND). To enter the programming mode close the jumper at the
moment of device connection to USB. During initialization bootloader checks the value at the
corresponding pin. If value is equal to zero, bootloader enters the programming mode.
If you want to launch user mode application after firmware update, you have to open the jumper
before bootloader resets the microcontroller. Otherwise it will enter the programming mode once
again.
Bootloader can also enter the programming mode with the help of EEPROM Mark.
The same pin can be used both for the jumper and for LED. First Bootloader verifies the value at
this pin. At zero value (when the jumper is closed), it enters the programming mode, configures the
pin as digital output, and outputs zero value there (LED is on). As an example of schematic solution
see PIC USB Demo Board.
Jumper use is configured in io_cfg.inc file with USE_JP_Bootloader_EN macro. To use the jumper
macros value must be set to 1.
#define USE_JP_Bootloader_EN 1
If the jumper is not used macros value must be set to 0.
#define USE_JP_Bootloader_EN 0
By default microcontroller pin E.0 is reserved for the jumper. If you need to use another pin change
the following macros:
in JP_Bootloader_PORT macros specify PORT register address;

in JP_Bootloader_TRIS macros specify TRIS register address;
in JP_Bootloader_PIN macros specify the pin number.
These macros are defined in io_cfg.inc file as shown below:
#define JP_Bootloader_TRIS TRISE
#define JP_Bootloader_PORT PORTE
#define JP_Bootloader_PIN 0
10.6.LED configuration
Bootloader operation mode is displayed on LED:
LED is on under programming mode microcontroller pin is configured as digital output

with output value equal to 0;
LED is blinking while bootloader updates user mode application;
LED is off under user mode microcontroller pin remains configured as digital input.
LED usage is configured in io_cfg.inc file by USE_LED macro. To use LED, macros value must be
set to 1.
#define USE_LED 1
If LED is not used, macros value must be set to 0.
#define USE_LED 0
By default microcontroller pin E.0 is reserved for LED functionality. To use another pin, change the
following macros:
in LED macros specify LAT register address;

in LED_TRIS macros specify TRIS register address;
in LED_PIN macros specify the pin number.
These macros are defined in io_cfg.inc file as shown below:
#define LED LATE
#define LED_TRIS TRISE
#define LED_PIN 0
10.7.USB Module - Vendor ID and Product ID

You have to specify valid Vendor ID and Product ID. Vendor ID can not be chosen arbitrarily. To
obtain valid Vendor ID contact the USB Implementers Forum. Product ID is assigned by the
equipment manufacturer in accordance with its own policies. All necessary information about
Vendor ID and Product ID assignment can be found at the USB Implementers Forum.
USB Vendor ID and Product ID are specified inside the USB device descriptor. All bootloader
descriptors are defined inside the usb_desc.asm file. This file uses macros from the usb_desc.inc
file. You have to modify these macros.
To specify USB Vendor ID and Product ID, modify BOOTLOADER_VID and

BOOTLOADER_PID macros. These macros are defined in usb_desc.inc file as shown below:
#define BOOTLOADER_VID 0x1234
#define BOOTLOADER_PID 0x5678
These macros values should correspond to real USB Vendor ID and Product ID.
10.8.XTEA - The Encryption Key

XTEA encryption algorithm has been added to the bootloader to prevent unauthorized copying of
user mode applications.
For successful firmware update user mode application should be encrypted with exactly the same
XTEA key that was specified in the bootloader. Bootloader code is programmed into Flash memory
at the production stage and is protected from reading by PIC microcontroller hardware. The end
user is unable to find out the XTEA key and to decrypt application HEX file. You can send
encrypted versions of user application to clients, and dont worry if they can be used in other
devices.
To change the XTEA key you have to modify constant value XTEA_KEY. Key length is 16 bytes.
This constant is defined in xtea.asm file as shown below:
;------------------------------------------------------
XTEA_KEYS_SECTION CODE_PACK 0x001C ; Place ROM constants after vectors
XTEA_KEY db "abcdefghijklmnop" ; 16 byte Key
The key can be set as a string or as a bytes sequence, e.g.:
;------------------------------------------------------
XTEA_KEYS_SECTION CODE_PACK 0x001C ; Place ROM constants after vectors
XTEA_KEY db 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68
0x69, 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x6F, 0x70 ; 16 byte Key
Besides the key it is possible to change encryption algorithm iterations number. The iterations
number defines protection level. 64 iterations set as default.
If you change iterations number, you have also to change DELTA_ITER value. DELTA_ITER
should be equal to DELTA * XTEA_ITERATIONS.
For example:
XTEA_ITERATIONS equ 0x40 ; Number of iterations on x1,x2
DELTA_ITER db 0x40,0x6e,0xde,0x8d ; Delta*XTEA_ITERATIONS
In case of iterations number change in Bootloader code, one has to make identical changes in
encoder application. This program is used to encrypt user application.
11.USB interface implementation

HID transactions
Preliminary information
Standard USB requests processing
USB State Machine
11.1.HID transactions
Bootloader uses HID protocol to interact with PC software. We provide fw_update program
that sends user-mode application to bootloader.
; HID Class-Specific Descriptor included in configuration
USB_HID_DESC
USB_HID_DESC_bLength db (USB_HID_DESC_end - USB_HID_DESC)
; Size
USB_HID_DESC_bDscType db DSC_HID ; HID descriptor type
USB_HID_DESC_bcdHID dw 0x0101 ; HID Spec Release Number in BCD
format
USB_HID_DESC_bCountryCode db 0x00 ; Country Code
; (0x00 for Not supported)
USB_HID_DESC_bNumDsc db HID_NUM_OF_DSC ; Number of class
descriptors
USB_HID_DESC_HDR_bDscType db DSC_RPT ; Report descriptor type
USB_HID_DESC_wDscLength dw (USB_HID_RPT_end - USB_HID_RPT)
; Size of the report descriptor
USB_HID_DESC_end

HID Report Descriptor is defined in the same file:
;------------------------------------------------------
; Report descriptor
USB_HID_RPT
db 0x05, 0x0C ; Usage Page (Consumer devices)
db 0x09, 0x00 ; Usage (unassigned)
db 0xA1, 0x02 ; Collection (datalink)
db 0x95, HID_IN_EP_SIZE ; report count 8
db 0x75, 0x08 ; report size 8
db 0x81, 0x00 ; input
db 0x95, HID_OUT_EP_SIZE ; report count 8
db 0x75, 0x08 ; report size 8
db 0x91, 0x00 ; output
db 0xC0 ; End Collection
USB_HID_RPT_end

HID requests are processed by usb_sm_HID_request subprogram.
Bootloader supports the following HID requests:
GET_DESCRIPTOR
with this request HOST determines the type and number of supported reports.
SET_REPORT
with this request host transfers data to bootloader.
11.2.Preliminary information
PIC USB Bootloader corresponds to the USB bus specification requirements for HID (Human
Interface Device) devices. This enables to use standard drivers developed by Microsoft company,
which are part of Windows operating system. For Linux users we provide library based on libusb
driver.
This chapter is about USB interface implementation in bootloader. The specificity of this section
requires knowledge of USB and HID protocols, and USB interface implementation in PIC18F4455
microcontroller.
USB and HID interfaces documentation, including the complete specification, is available at USB
Implementers Forum.
PIC18F4455 mmicrocontroller documentation is available at Microchip company site.
11.3.Standard USB requests processing

Standard USB requests are processed by usb_sm_ctrl subprogram in usb.asm file. This subprogram
identifies request type and the calls the corresponding handler. Bootloader supports standard USB
requests, described in USB and HID specifications.
Bootloader uses HID interface to interact with PC software. HID transactions processing is
described in the section called HID transactions.
All standard USB requests host sends to Endpoint 0. Bootloader processes the following USB
requests:
GET_DESCRIPTOR;
GET_STRING;
SET_ADDRESS;
GET_CONFIGURATION;
SET_CONFIGURATION;
GET_INTERFACE;
SET_INTERFACE;
GET_STATUS.
11.4.USB State Machine

Like any other USB device, Bootloader processes standard USB requests and reacts to events at
USB bus. USB bus events processing is implemented as a state machine in usb_state_machine
subprogram in boot.asm file.
Bootloader reacts to the following events:
ATTACH and DETACH

Attachment to USB bus and detachment. At attachment (ATTACH) internal state is reset to
default values and Bootloader enters the wait mode for RESET command. At detachment
(DETACH) Bootloader enters attachment wait mode.
RESET
USB bus reset. When bootloader receives the RESET command it configures Endpoint 0
and enters USB initialization mode. During initialization host assigns to device a unique,
different from zero address (enumeration).
SUSPEND and RESUME
Switch to energy saving mode and exit it. When bootloader receives SUSPEND command it
stops processing USB requests and enters the energy saving mode. Bootloader exits energy
saving mode when it receives RESUME command.
IDLE
Switch to inactive state. When bootloader receives IDLE command it enters the inactive
state. To exit from inactive state RESET command must be received.
STALL
Reaction to unsupported requests or errors at USB bus.
Downloads
Windows 7, Vista, XP, 2000, NT, 98
Package Version Date Release Notes Key Features
bootloader-0.2.2.zip 0.2.2 05 Apr 2009 Added PC software
Linux, FreeBSD, NetBSD, OpenBSD, Darwin, MacOS

Package Version Date Release Notes Key Features
bootloader-0.2.2.tar.gz 0.2.2 05 Apr 2009 Added PC software
SW Tools & Utilities

Diolan provides comprehensive set of SW applications to get instant access to all USB PIC
bootloader features. Our SW installation package includes source code of these applications.
Application
Key Features
Name
fw_update This program transfers data to bootloader for burning into the microcontroller
memory. It can also be used to read data and verify data after burning.
encoder This program encrypts/decrypts data file using the XTEA algorithm.

USB BootLoader

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

USB BootLoader

Hochgeladen von

Copyright:

Verfügbare Formate

Documentation

Bootloader utilizes memory self-programming ability of PIC18F4455 microcontrollers. Once

To compile the bootloader you will need:

4.Bootloader programming into the target PIC18F

Table 8.1. Encoder commands

Short Full Parameter

-h -help Displays the supported commands and options description.

-c -convert Convert the file from one format to another.

Table 8.2. Encoder options

-ix -input_hex FILENAME Input file in Intel Hex Format.

-ib -input_bin FILENAME Input file in Binary Format.

string of two hex digits per byte (like 01202040ac).

-ob -output_bin FILENAME Output file in Binary Format.

To decrypt "example_encrypted.hex" use following command line:

Table 8.3. Fw_update commands

Short Command Full Command Description

-w -write Write data to device.

-r -read Read data from device.

-v -verify Verify device memory.

-e -erase Erase device memory.

-ver -version Display versions of fw_update and Bootloader if present.

-h -help Displays the supported commands and options description.

Table 8.4. Fw_update options

-vid -vendorid VID Device vendor ID.

-pid -productid PID Device product ID.

-t -reset YES | NO Reset device after operation is finished. Default: YES

Immediate mode - actual byte(s) specified in the command line. Data

fw_update -e -w -v -vid 0x04D8 -pid 0xFF04 -ix example_encrypted.hex

high priority interrupts vector must be located at address 0x0808;

Example for MCC18:

#pragma code high_vector=0x0808

9.PC and Bootloader Interaction Protocol

Before sending BOOT_ERASE_FLASH command you have to fill in boot_cmd_erase_flash

Command code; the given field must be initialized by BOOT_ERASE_FLASH constant

The number of 64-bytes blocks to erase. As programs memory in PIC18 microcontrollers is

BOOT_GET_FW_VER command is used to determine Bootloader version.

Command code; the given field must be initialized by BOOT_GET_FW_VER constant

The address from which flash memory read starts.

Flash memory size to read.

BOOT_READ_ID command is used to read the content of ID Locations of PIC microcontroller.

ID Locations are eight memory locations of PIC memory microcontroller (200000h-200007h).

Before sending BOOT_RESET command you have to fill in boot_cmd_reset structure:

Command code; the given field must be initialized by BOOT_WRITE_EEPROM constant

The address from which EEPROM memory write starts.

The size of the data block to write (in bytes).

Data to be written into the microcontroller EERPOM memory.

Before writing, flash memory must be erased by BOOT_ERASE_FLASH command.

Before sending this command you have to fill in boot_cmd_write_flash structure:

Command code; the given field must be initialized by BOOT_WRITE_FLASH constant

Data to be written into the PIC microcontroller ID locations.

To ease data processing boot_rsp_erase_flash structure can be used:

To ease data processing boot_rsp_get_fw_ver structure can be used:

Major version number.

Minor version number.

Sub minor version number.

To ease data processing boot_rsp_read_eeprom structure can be used:

The address, EEPROM memory reading starts from.

The size of the read data in bytes.

Data read from EEPROM memory.

To ease data processing boot_rsp_read_flash structure can be used:

LSB byte of the address, flash memory reading starts from.

MSB byte of the address, flash memory reading starts from.

The size of the data in bytes.

Data read from microcontroller flash memory.