EX FILE IMPORT .........................................................................................................................................21
EX FILE EXPORT.........................................................................................................................................21
LANK CHECK..............................................................................................................................................24
ART PARAMETERS ......................................................................................................................................32
This document covers design and theory of the PICkit 2 version 2 firmware and PC application software. Version 2
implements a script-based design to allow maximum flexibility for programming any type of device without
requiring frequent, part-specific changes and updates. All part-specific information is kept in a device file, allowing
new parts and families with new algorithms to be implemented without frequent changes to the software or
firmware.
2.0Guiding Design Goals
The guiding design goals of the version 2 firmware
1.Allow the firmware and software to be as generic as possible so adding new part & family support requires
little to no changes.
2.Remain compatible with bootloader commands for the existing Pk2.
3.All device specific information should be kept in the device file.
4.The scripting and firmware should be flexible enough to allow other tasks besides programming to be
accomplished, such as ICD.
3.0Architecture Overview
The PICkit 2 is organized into 4 functional blocks.
1.Bootloader
2.Programmer Firmware
3.PC Application
4.Device File
The Bootloader is designed to be autonomous i.e. does not require programmer firmware for operation.
The Programmer firmware, however, has its own USB stack, and does not rely on the bootloader for communication
while running. This allows the USB stack used during normal execution to be updated over USB using the
bootloader.
The programmer firmware is largely a script execution engine, with basic commands for management of scripts and
data. Data is program code, EE contents, and other information for which the programmer only acts as a conduit.
The PC application is responsible for the user interface portion of the system. Its function is to respond to user
requests by packaging data and scripts for execution by the firmware.
The device file contains all scripts and descriptions of each part supported. It is divided into 3 main sections. The
first is the family description section, which sets up some parameters common to all family members. The second is
the part description section, with an entry for each part supported. This description references scripts contained in
the third section, and defines membership in a family defined in section 1. The third section contains an indexed
listing of all scripts used by the supported parts.
The firmware consists largely of commands to store and retrieve data from 2 data buffers, and to store and execute
scripts from an indexable script buffer.
The names & uses of the buffers are:
Download Data Buffer
256 byte circular buffer. Stores data sent by the PC host for use by script commands. This is
where code and data to be programmed by a script is stored. The write pointer is advanced by
USB commands that write to the buffer, and the read pointer is advanced by scripts that use the
data.
Upload Data Buffer
128 byte circular buffer. Data retrieved by a script is stored here to be read over USB by the PC
host. Data and code read from a part by a script is stored here. The write pointer is advanced by
scripts that place data into the buffer, and the read pointer is advanced by USB commands to
retrieve the data.
Script Buffer
768 byte indexed buffer. This buffer stores up to 32 scripts of variable sizes up to 768 bytes total.
The Script Index Table stores the beginning location and length of each script 1 through 32.
Currently scripts are limited in length to 62 bytes as that is the longest script than can be sent
via a DOWNLOAD_SCRIPT command in a 64-byte USB packet.
5.1Firmware Commands
A command packet starts with the command byte and is followed by the command data bytes in order starting with
data[1]. Response data bytes are returned via USB starting at data[1].
Any command not defined is treated as a “No Operation”.
argument value.
0x85 READ_BANDGAPCommand:0Reads the bandgap of 12F629 family devices
0x86 WRITE_CFG_BANDGAPCommand:0Writes the Config word of 12F629 family
devices with the read badgap value.
0x87 CHANGE_CHKSM_FRMTCommand:2data[1] = Format
data[2] = 0
Format = 0 for most devices
= 1 for Baseline / Midrange flash
= 2 for Baseline / Midrange EE
* If a script attempts to use data from the download buffer and it is empty, the script will abort and generate a status
error. If a script attempts to place data in the upload buffer and it is full, the script will abort and generate a status
error.
Each command that provides a response will generate a separate USB read packet with only the data from that
command. Each packet is set up as a blocking USB read. Thus, multiple commands may be stacked into a single
USB Write packet, but a seperate USB read must be completed to retrieve the result for each command that returns a
response. The response packets will be read in the order in which the commands appear in the Write packet.
Results from multiple commands in a single Write packet are not appended to a single Read packet.
This allows data to immediately available from a command after it has executed, without waiting for the entire USB
Write packet to be processed. Data can be read as it is available even if a script with a long execution time (such as
bulk erase) appears later in the command list.
5.1.2UART Mode
UART Mode allows the PICkit 2 to be used as a simple UART.
ICSPCLK = TX (data transmitted from the PICkit 2)
ICSPDAT = RX (data received from target UART)
Signal levels are inverted (ie Start Bit = GND) logic level signals between GND and VDD.
A bit in the high status byte returned by the READ_STATUS command allows determination if the PICkit 2 is in
UART Mode or not.
Restrictions:
VPP will be shut off when UART mode is entered.
Scripts will not be run in UART mode if script commands are received.
The PICkit 2 VDD pin needs to be connected to the target VDD so the ICSP signals are clamped to the
proper voltage, regardless of whether PICkit 2 is powering the target or not.
In UART mode, any data written to the Download Data Buffer will be transmitted on the TX pin at the specified
baud rate.
Any received data on the RX pin will be placed in the Upload Data Buffer. The PC host should poll the buffer for
data using the UPLOAD_DATA command. The Length byte in the response packet allows determination if any
data was received.
Note that the Upload Data Buffer may be overrun if the host does not keep up with the received data rate. Overflow
data will be lost.
Data Buffers should be cleared before putting the unit in UART Mode
The BUSY LED acts as an activity light (for both RX and TX).
Baud rates faster than 38400 may not work reliably.
5.1.3Unit IDs
A PICkit 2 unit may be assigned a unique Unit ID string of up to 15 characters. This string is stored in 16 bytes of
internal EEPROM on the PICkit 2 PIC18F2550. A value string is always preceded by the char byte ‘#’ to indicate a
valid string. If this first byte is not ‘#’, the Unit ID is assumed to be blank.
Starting with PICkit 2 Firmware v2.32.00, the Unit ID is returned in the PICkit 2USB Descriptor for Serial Number
String. This allows the Unit ID to be read from the USB descriptors without sending any HID commands, so
software may detect and list all attached PICkit 2 units without risking corrupting any current communications with
a PICkit 2 unit if it were to send HID commands.
Execution of a script will abort on the following conditions:
-Script is attempting to use bytes from the Download Data Buffer and the buffer is empty.
-Script is attempting to store bytes in the Upload Data Buffer, and the buffer is full.
-ICD Timeout or BusError bit is set.
RUN_SCRIPT and EXECUTE_SCRIPT commands will be ignored when any of StatusHigh bits 7:1 are set (i.e. a
script error exists) until the error is acknowledge and cleared by a READ_STATUS command.
Some script control bytes require arguments. Argument bytes follow the control byte directly, in the order given in
the table. All undefined byte values will be interpreted as “no operation.”
IDControl ByteArgumentsDescription.
0xFFVDD_ON-Turns on VDD PFET pass transistor.
0xFEVDD_OFF-Turns off VDD PFET pass transistor.
0xFDVDD_GND_ON-Turns on VDD NFET ground.
0xFCVDD_GND_OFF-Turns off VDD NFET ground.
0xFBVPP_ON-Turns on VPP PNP pass transistor.
0xFAVPP_OFF-Turns off VPP PNP pass transistor.
0xF9VPP_PWM_ON-Start up VPP PWM. Allow 100ms to
come up to voltage.
0xF8VPP_PWM_OFF-Shut down VPP PWM. Q4 is off
(VPP_PUMP low).
0xF7MCLR_GND_ON-Turns on VPP NPN ground.
0xF6MCLR_GND_OFF-Turns off VPP NPN ground.
0xF5BUSY_LED_ON-Turns on BUSY LED
0xF4BUSY_LED_OFF-Turns off BUSY LED
0xF3SET_ICSP_PINSarg[1] = pin states