Embed Inc PIC Programmers Host Protocol Specification
Version 29.12, 29 October 2022
This document describes the Embed Inc PIC programmer communications
protocol. This protocol is used to communicate between a host computer
and a PIC programmer, such as the Embed Inc EasyProg, ProProg, USBProg,
and LProg programmers.
Revisions
1.0, 1 June 2003
First released version.
1.1, 2 June 2003
Minor typo fix.
1.2, 18 August 2003
Updated to firmware version PRG 4.
1.3, 8 August 2004
Fixed to add reset ID 3. Was in firmware but omitted from
this document.
5.0, 17 August 2004
Added new commands to support ProProg features not present on
the EasyProg. Started new spec revision numbering system that
leaves off from the old firmware version numbers.
Redefined CVLO and CVHI return values of the FWINFO command.
Added commands FWINFO2, RESADR, and CHKCMD.
Added IDWRITE ID 3 and IDREAD ID 3.
5.1, 21 August 2004
Added clarification to FWINFO command description about how
host software should determine the set of commands implemented
in the firmware.
Added clarification to FWINFO2 command description about what
to assume when the FWINFO2 command is not available.
6.0, 7 September 2004
Added commands GETPWR, GETVDD, and GETVPP.
7.0, 12 September 2004
Added WAITCHK command.
8.0, 16 September 2004
Added commands GETBUTT, APPLET, and RUN.
8.1, 18 September 2004
Minor typo fix. Added clarification to APPLED command.
9.0, 1 October 2004
Added HIGHZ and NTOUT commands. Clarified power up and host
input timeout state.
9.1, 6 November 2004
Noted spec revisions the various reset, read, and write IDs
are required in. This was previously mentioned only in the
revision history, is now mentioned in the descriptions of the
commands that set the IDs.
10.0 28 November 2004
Added GETCAP command. Variable Vdd is optional if so
described by the GETCAP command. Reset ID 3, write IDs 1-3,
and read IDs 1-3 are now optional if so described by the
GETCAP command. These IDs were required in previous
versions. Commands PINS, VDDVALS, VDDLOW, VDDHIGH, TEST1,
PAN18 were previously required and are now optional.
11.0 16 February 2005
Added optional commands SEND3, SEND4, RECV3, RECV4, W30PGM,
TEST2, R30PGM, and DATADR. Added RESET ID 4, write ID 4, and
read ID 4. All these new IDs support the dsPIC target type.
12.0 27 March 2005
Added write ID 5 to support PIC 16F87xA.
13.0 9 April 2005
Added write ID 6 to support PIC 16F716.
14.0 26 June 2005
Added write IDs 7 and 8, read ID 5, and WBUFSZ command.
15.0 3 July 2005
Added VPP command and GETCAP ID 4. This allows the host to
determine how the programmer Vpp capabilities and provides a
means for controlling the Vpp level when that is supported by
a programmer.
16.0 22 September 2005
Added reset ID 5, write ID 9, and WBUFEN command. These are
required to support 16F87/88.
17.0 15 October 2005
Added write ID 10 to support 16F77 and related.
18.0 5 November 2005
Redefined high bit of IDRESET ID parameter to indicate Vdd
should be removed before Vpp when turning off the target.
Previously all 8 bits were the ID, now only the low 7 bits.
19.0 29 January 2005
Added GETTICK command to accomodate programmers with other
than 200uS internal clock tick period. Added VDD command for
programmers that handle only a single Vdd value at a time.
The older VDDVALS, VDDLOW, and VDDHIGH commands are considered
obsolete and new programmers are encouraged to implement the
VDD command instead. The VDDNORM command must always be
available and enables Vdd to its "normal" level using the old
method, or to the single specified value using the new
method. IDWRITE now resets the next Vdd level to 5V and the
next Vpp level to 13V.
19.1 8 July 2006
Added description of how protocol is implemented over USB. No
change to protocol over RS-232 as described in version 19.0.
19.2 6 August 2006
Minor wording change to better describe WAITCHK return byte.
19.3 7 August 2006
Minor typo fix in VPPOFF command description.
20.0 10 September 2006
Added NAMESET and NAMEGET commands.
21.0 13 October 2006
Added REBOOT command.
22.0 12 November 2006
Added READ64 command.
22.1 13 November 2006
Fixed typo in READ64 command description.
23.0 17 February 2007
Add write ID 11.
23.1 12 May 2007
Added mention of ID 2 to FWINFO2 command, indicating the USBProg
firmware. The protocol has worked this way since the USBProg was
created. This is a documentation fix only.
24.0 12 January 2008
Added IDRESET ID 6 to support 18FJ devices.
25.0 11 April 2008
Added IDRESET ID 7 to support 24H and 33F devices.
26.0 16 June 2008
Added GETCAP 0 1 for programmers that implement a single fixed
Vdd voltage.
27.0 19 June 2008
Added the implementation specific commands 240-255.
28.0 8 July 2008
Added VPPHIZ command.
29.0 11 Aug 2008
Added TESTGET and TESTSET commands.
29.1 12 Nov 2009
Added IDRESET ID 8 to support 24F devices.
29.2 4 Jan 2011
Added IDRESET, IDREAD, and IDWRITE IDs to support the 16F182x
subfamily. These are the first of the enhanced (4 digit model
number) PIC 16 supported.
29.3 22 Oct 2011
Added reset ID 10 to support 24FJ parts.
29.4 2 Jan 2015
Added commands EECON1, EEADR, EEADRH, and EEDATA. These are
optional, but necessary for supporting some of the newer PIC 18
which have these registers at different addresses than all
previous PIC 18.
29.5 6 Feb 2015
Added reset ID 11.
29.6 11 Oct 2015
Added 12 bit core parts to DATADR command description.
29.7 20 Feb 2016
Added support for PIC 24EP and dsPIC 33EP series. This
included:
Added commands VISI, TBLPAG, NVMCON, NVMKEY, NVMADR,
NVMADRU, FTICKF, and TPROGF.
Added IDRESET ID 12.
The IDRESET command now causes all assumed target register
addresses to be reset to their defaults.
29.8 13 Dec 2016
Added SENDSER and RECVSER commands.
29.9 28 May 2018
Added read ID 7 and write ID 13. Added commands SEND8M, SEND24M,
and RECV24M. These changes were to support the programming
protocol that uses 8 bit opcodes and 24 bit data words. This
seems to be the "new" 16F1xxxx protocol, first introduced in
parts like the 16F15313.
29.10 22 Oct 2018
Added enhanced 14 bit core parts to DATADR description.
29.11 14 Dec 2021
Added reset ID 13 to support 16F153xx.
29.12 29 Oct 2022
Added read ID 9 and write ID 15 to support 18F25Q10 and related.
Overview
A host computer communicates with the programmer via a bi-directional
stream of bytes. The protocol is independent of the underlying
transport medium except as noted in the following sections.
Communication is bidirectional, but the unit only sends data in direct
response to commands from the host. All host commands start with an
opcode byte to identify the command, followed by data bytes (if any)
that are dependent on the particular command. A command may result in
the unit sending response bytes to the host. The format of these
response bytes, if any, is dependent on the particular command they are
sent in response to.
Unless otherwise noted, individual values are unsigned bytes, and multi-
byte values are sent in least to most significant byte order.
RS-232 transport
The RS-232 settings are 115.2 kBaud, 1 start bit, 1 stop bit, 8 data
bits, no parity, no flow control. This interface is not inherently
flow controlled, so a ACK byte is sent in response to every command.
See the Flow Control section (below) for details.
USB transport
Endpoint 1 configured for bulk transfers is used in both directions to
implement the bi-directional stream of bytes. This interface is
inherently flow controlled, so no ACK byte is sent in response to
every command.
Flow control
In many cases the unit can not process all commands at the speed with
which they can be sent from the host. Flow control has been built into
the protocol to avoid overruns in those cases where the underlying
transport does not already provide flow control and guarantee overrun
prevention.
When flow control is implemented in this protocol, every valid command
is acknowledged with an ACK response when processing of a command opcode
byte begins. The host must not send a new command before receiving the
ACK from the previous. This guarantees that the maximum unprocessed
bytes the unit needs to store is two commands minus one byte.
For example, assume the host wants to send a string of commands that
have 8 data bytes each. The host sends the 9 bytes of the first command
(1 opcode byte, 8 data bytes). The unit is busy processing the previous
command, so these 9 bytes are stored but not processed immediately. The
host now stalls because a complete command has been sent but no ACK
received yet. After the unit completes the previous command, it fetches
the opcode byte of the stored command, validates it, then sends the ACK
response. The host is now free to send the next command, which is
another 9 bytes total. Worst case, the unit now has the 8 data bytes of
the first command plus all 9 bytes of the second command in its input
buffer. This is the maximum, because the 8 data bytes of the first
command and the opcode byte of the second command will have been removed
from the input buffer before the next ACK is sent.
An ACK response is a single byte with the value 1.
Command stream timeout
An input stream timeout occurs (if enabled) when there are 5 or more
seconds between bytes from the host. The timeout is enabled at power
up and whenever an opcode byte is received. It is disabled by
selected commands, like RUN and NTOUT. The timeout is also
temporarily disabled during any deliberate wait interval, although
these are generally much shorter than 5 seconds.
The unit assumes communication with the host has been lost on a timeout.
It therefore aborts any command in progress and resets to the power up
state. This includes setting all target PIC lines to the most benign
and least intrusive state, which is the same as if the HIGHZ command had
been executed. The STATUS LED will show the idle state, and the APP LED
(if present) will be off.
The 5 second host timeout can be disabled by installing the jumper
labeled "Debug" on the circuit board. This allows for single stepping
the host software during debugging when there can be large delays
between individual bytes and it would be undesirable for the unit to
abort a command and reset. Different programmers may not implement this
timeout at all.
Commands
This section describes all the valid commands and their responses, if
any. For each command, the command name is shown first, followed by a
colon and the decimal value of the opcode byte. The description of data
bytes, if any, follows. If the unit sends bytes in response to the
command, these are shown on a separate line starting with "RSP:". If
the command was defined at version 5 of this spec or later, then the
lowest spec version including this command is also indicated on a
separate line.
Some commands are optional, starting at version 6. These are indicated
by "optional" following the spec version number they were first defined
in. In this case, the host must use the CHKCMD command to determine
whether the optional command is present. It is recommended that the
CHKCMD command be used to determine the availability of all commands in
any case when the firmware reports spec version 5 or later.
Commands with no starting version listed must be implemented by all
firmware. Commands with a specific version listed and not indicated as
optional must be implemented by any firmware claiming compatibility with
the spec version listed for that command or greater.
All commands were implemented in the official firmware version 2 unless
otherwise noted. Firmware version 2 was the first publicly released
version, so this represents the minimum guaranteed baseline command set.
Applications should inquire the firmware version using the FWINFO
command to determine the command set versions supported. See details in
the FWINFO command description.
When flow control at the protocol level is in use, all valid commands
cause an ACK response to be sent before any response bytes for the
command. This ACK response is implied, and not shown in the
descriptions below.
Unless explicitly stated to the contrary, all necessary wait times
required due to the programmer itself (not the target chip) are
automatically guaranteed. For example, the VPPON (enable programming
voltage) command starts an internal wait so that subsequent commands are
not processed until the programming voltage has stabalized. There are
built in waits for all changes to Vpp and Vdd. Therefore, a command to
change Vpp or Vdd can be immediately followed by commands that need to
be executed with the new settings. The host command stream will
automatically be slowed down as needed by the flow control mechanism.
Invalid command opcode bytes are ignored. No ACK response is sent for
these.
The valid commands are:
NOP: 1
No operation (but ACK response is sent if using protocol flow
control, as with all valid commands).
OFF: 2
Power down the target chip. Vdd and Vpp are both set to 0 volts.
PINS: 3
RSP: <data>
(Optional at version 10 or higher)
Returns status that gives some information about how many pins the
target chip has. The bits in DATA mean:
bit 0 (LSB) - 1 if chip has 18 or less pins, 0 if more than 18
All remaining bits are reserved and set to 0. Reserved bits may
have meaning in future versions.
This value is only correct if the target chip is in the built-in
programming socket. It is not valid on units that do not have a
programming socket, or that are performing in-circuit programming
whether a programming socket is present or not.
SEND1: 4 <n> <data>
Send up to 8 data bits to the target chip. N must be 0-7 and is
the number of bits to send - 1. DATA is the data to send, starting
with the LSB.
SEND2: 5 <n> <i16 data>
(Optional at version 11 or higher)
Send up to 16 data bits to the target chip. N must be 0-15 and is
the number of bits to send - 1. DATA is the data to send, starting
with the LSB.
SEND3: 52 <n> <i24 data>
(Version 11, optional)
Send up to 24 data bits to the target chip. N must be 0-23 and is
the number of bits to send - 1. DATA is the data to send, starting
with the LSB.
SEND4: 53 <n> <i32 data>
(Version 11, optional)
Send up to 32 data bits to the target chip. N must be 0-31 and is
the number of bits to send - 1. DATA is the data to send, starting
with the LSB.
RECV1: 6 <n>
RSP: <data>
Read up to 8 data bits from the target chip. N must be 0-7 and is
the number of bits to read - 1. The returned bits are justified
into the LSB end of DATA with the upper unused bits of DATA set to
0. The bits are read in least to most significant order. The
first bit read is returned in bit 0, the second in bit 1, etc.
RECV2: 7 <n>
RSP: <i16 data>
(Optional at version 11 or higher)
Read up to 16 data bits from the target chip. N must be 0-15 and
is the number of bits to read - 1. The returned bits are justified
into the LSB end of DATA with the upper unused bits of DATA set to
0. The bits are read in least to most significant order. The
first bit read is returned in bit 0, the second in bit 1, etc.
RECV3: 54 <n>
RSP: <i24 data>
(Version 11, optional)
Read up to 24 data bits from the target chip. N must be 0-23 and
is the number of bits to read - 1. The returned bits are justified
into the LSB end of DATA with the upper unused bits of DATA set to
0. The bits are read in least to most significant order. The
first bit read is returned in bit 0, the second in bit 1, etc.
RECV4: 55 <n>
RSP: <i32 data>
(Version 11, optional)
Read up to 32 data bits from the target chip. N must be 0-31 and
is the number of bits to read - 1. The returned bits are justified
into the LSB end of DATA with the upper unused bits of DATA set to
0. The bits are read in least to most significant order. The
first bit read is returned in bit 0, the second in bit 1, etc.
CLKH: 8
Set the clock line to the target high.
CLKL: 9
Set the clock line to the target low.
DATH: 10
Set the data line to the target high.
DATL: 11
Set the data line to the target low.
DATR: 12
RSP: <data>
Read the data line from the target. The result is returned in the
low bit of DATA. Unused DATA bits are set to 0.
TDRIVE: 13
RSP: <data>
Test whether the target chip is driving the data line. DATA is
returned 1 if the target is driving the line and 0 if the target is
in high impedence state.
WAIT: 14 <i16 ticks>
Force a minimum wait time before the next operation is performed on
the target chip. The wait time is the number of internal clock
ticks to wait for. Up to spec version 18 the clock tick period was
defined to be 200 us. Starting at version 19 it can be a different
value if the GETTICK command is implemented. The host command
stream timeout is disabled during the wait time.
GETTICK: 64
RSP: <I16 ticktime>
(Version 19)
Indicates the period of the internal clock ticks that will be used
with the WAIT, TPROG and other commands that require a clock ticks
parameter command. TICKTIME is an unsigned 16 bit integer in units
of 100 ns. The default is 200 us when the GETTICK command is not
implemented.
FWINFO: 15
RSP: <org> <cvlo> <cvhi> <vers> <i32 info>
Return version and other information about this firmware. The
returned values are:
ORG: 1-254 ID of the organization that is responsible for this
firmware. A value of 1 indicates this is in the sequence of
official released firmware. Values of 0 and 255 are reserved.
CVLO: 1-254 lowest version of this spec that the firmware is
backwards compatible with. 0 indicates not compatible with
any offical release. 255 is reserved.
CVHI: 1-254 highest version of this spec that the firmware is
compatible with. 0 indicates not compatible with any offical
release. 255 is reserved.
VERS: 1-254 sequential version number within the organization
responsible for this firmware. 0 and 255 are reserved.
INFO: Arbitrary 32 bits of information private to the
organization responsible for this firmware. This value is
always 0 for an official version.
This command was slightly redefined in spec version 5. Previously,
the CVLO and CVHI fields indicated the lowest and highest official
firmware versions that this particular firmware was compatible
with. To support multiple firmware tracks on different devices,
these fields have been changed to refer to the major versions of
this specification.
The range of CVLO and CVHI values reported by any publicly released
firmware at the time of spec version 5 was 2-4. Host software
should therefore interpret CVHI and CVLO values of 2-4 to imply
compatibility with spec version 1, whereas values of 5 or more
specifically indicate the spec version number.
The procedure for the host software to determine which commands are
available in the firmware is:
1) Issue the FWINFO command. If the CVHI value is less then 2,
stop. Firmware version 1 was not publicly released and is not
supported. The programmer firmware must be upgraded.
2) If the CVHI value from the FWINFO command is 2-4, then
commands 1-38 may be used. All other commands are illegal.
3) If the CVHI value from the FWINFO command is 5 or greater,
then the CHKCMD command (41) is available. The CHKCMD command
should be used to inquire about all possible commands to get
the complete list of available commands.
FWINFO2: 39
RSP: <firmware ID>
(Version 5)
Provides additional information about the target firmware and
hardware. A FWINFO command must always be issued before FWINFO2 to
determine whether the FWINFO2 command is available. The FWINFO2
values are interpreted within the context of the FWINFO values. The
returned values are:
FIRMWARE ID: ID of the firmware branch or track. These numbers
are uniquely assigned by each organization as identified by
the ORG value of the FWINFO command. For the official line
of firmware (ORG = 1), the values are:
0 - PRG firmware. This is the standard controlling
firmware of the EasyProg.
1 - PPRG firmware. This is the standard controlling
firmware of the ProProg.
2 - EUSB firmware. This is the standard controlling
firmware of the USBProg and USBProg2.
3 - LPRG firmware. This is the standard controlling
firmware of the LProg.
The host software should act as if FIRMWARE ID is 0 when this
command is not available, which is in spec version 1.
VDDVALS: 16 <low> <norm> <high>
(Optional at version 10 or higher, see GETCAP and VDD commands)
Set the low, normal, and high target chip supply voltage levels.
Each value is the supply voltage level where 0 - 250 maps to 0 - 6
volts. In other words, the values are in units of 24mV. Each
value must be in the range of 0 - 250. The default for normal is 5
volts (NORM = 208). Applications should not rely on defaults for
the low and high voltages.
This command is being discouraged for new programmer
implementations in favor of the simpler VDD command. Programmers
no longer need to store 3 different Vdd levels.
VDD: 65 <level>
(Version 19, optional)
Set the Vdd voltage level. The 0-250 range of LEVEL maps to 0-6
volts, which also means that LEVEL is in units of 24mV.
For the new value to take effect, Vdd must first be set to off or
high impedence, then enabled (with VDDNORM command).
The Vdd level is set to 5V (LEVEL = 208) on power up, or by the
IDWRITE command.
VDDLOW: 17
(Optional at version 10 or higher, see GETCAP command)
Set the target chip supply voltage to the "low" level. This
command is discouraged. See the VDDVALS command description.
VDDNORM: 18
Enable Vdd drive to the indicated level set by the VDD command, or
the "normal" value set by the VDDVALS command. When the VDD
command is used to set the VDD level instead of the deprecated
VDDVALS command, VDDNORM is the "turn on VDD" command.
VDDHIGH: 19
(Optional at version 10 or higher, see GETCAP command)
Set the target chip supply voltage to the "high" level. This
command is discouraged. See the VDDVALS command description.
VDDOFF: 20
Turn off the target chip power supply. This sets Vdd to 0.
VPPON: 21
Turn on the target chip programming voltage. The voltage level is
set by the VPP command, or defaults to 13V when the VPP command is
not present.
VPPOFF: 22
Turn off the target chip programming voltage. This sets Vpp to 0
volts.
VPPHIZ: 70
(version 28, optional)
Set the Vpp line to high impedence to the extent possible. This
command results in Vpp being driven with a higher impedence than
the VPPOFF command does. Programmers that can not drive Vpp to a
third and higher impedence state from VPPON and VPPOFF must not
implement this command.
VPP: 61 <Vpp level>
(Version 15, optional)
Set the Vpp voltage to use when Vpp is enabled. The argument is an
unsigned byte with the 0-255 range linearly mapped to 0-20 volts.
The resolution is therefore about 78mV. This value is reset to the
default of 13V by the IDWRITE command. The VPP command must
therefore be issued after the IDWRITE command. For example, the
parameter byte value for a Vpp level of 11.5 volts is (11.5 / 20) *
255 = 147.
Programmers are not obligated to implement the full range of
values. Programmers that provide other than a fixed Vpp level of
13 V must implement GETCAP ID 4. The resulting Vpp value is
undefined if the command parameter is outside the range indicated
by the GETCAP command.
IDRESET: 23 <id>
Selects the algorithm for the RESET operation, resets the RESADR
value to 0, and resets the assumed addresses of target chip
registers to their defaults.
The ID parameter contains two fields.
The high bit indicates the Vpp versus Vdd order to use when turning
off the target chip. 0 indicates to lower Vpp first, then remove
Vdd. 1 indicates to remove Vdd first, then lower Vpp. In general,
it is best to assert MCLR (lower Vpp) while other changes are being
made, except that the MCLR role of the Vpp pin can be disabled in
the config word of some targets. In those cases, the target may
start running if Vpp is removed but Vdd remains. For those
targets, the Vdd first method should be specified.
WARNING: The definition of the high bit of ID changed in spec
version 18. Previously the entire ID byte was the reset algorithm
ID and the Vpp/Vdd power off order was not specified. This bit
must be set to 0 for any firmware versions that are only compatible
with spec versions below 18, but this bit is significant for later
firmware versions. This makes version 18 incompatible with
previous versions, and any firmware that claims compatibility with
version 18 or higher must not claim compatibility with versions
below 18.
The low 7 bits of the the ID byte are the reset algorithm ID. IDs
0-3 are required for versions 1-9. IDs of 3 and greater are
optional starting in version 10. If other than IDs 0-3 are
supported, this must be reported by the GETCAP command. Valid
values of ID are:
0: None. Dummy algorithm that performs no action.
1: Vpp before Vdd. The Vpp programming voltage is raised before
the target chip Vdd power supply voltage. This is required by
some PICs, such as the 16F628. The target address is assumed
to be the RESADR value after reset.
2: Vdd before Vpp. The Vdd target chip power supply voltage is
raised before the Vpp programming voltage. This is required by
some PICs, such as the 18F452. The target address is assumed
to be the RESADR value after reset.
3: Vdd before Vpp. Like ID 2 except that the target address will
be unknown after this reset
4 (Version 11, optional): For 30F (dsPIC) target types. The
RESADR value is ignored. There is no need to send a RESADR
command.
5 (Version 16, optional): Vdd before Vpp, but with a short time
between them. The 16F88 requires there be no more than 250 us.
Other target chips may require an even shorter time. The
programmer should make the time from Vdd to Vpp as short as
possible, but certainly no more than 250 us.
6 (Version 24, optional): Special enter program mode sequence used
by the 18F25J10 and others. Vdd is raised first, then Vpp
blipped briefly, then a special 32 bit code is clocked in, then
Vpp raised again.
7 (Version 25, optional): Special enter program mode sequence used
by 24H and 33F devices. Vdd is raised first, then Vpp blipped
briefly, then a special 32 bit code is clocked in, then Vpp
raised again. The RESADR value is ignored. There is no need
to send a RESADR command.
8 (Version 29, optional): For 24F parts.
9 (Version 29, optional): For 16F182x parts, and probably other
enhanced PIC 16. Holds Vpp low and clocks in the special
unlock key sequence for these parts. Vpp continues to be held
low during all programming operations. The target address is
considered unknown after this reset to force a reset address
command to be issued. The RESADR value is irrelevant and there
is no need to send a RESADR command.
10 (Version 29, optional): For 24FJ parts.
11 (Version 29, optional): For 18FxxK80 high voltage program entry
mode. Vdd is applied, then Vpp raised to a high voltage, then
a special 32 bit code clocked in.
12 (Version 29, optional): For PIC 24EP and dsPIC 33EP. Adds
additional wait time in some places, and additional NOP
instructions in certain sequences.
13 (Version 29, optional): For 16F153xx and possible others. Holds
Vpp low, then clocks in the 32 bit signature "MCHP" in MSB to
LSB order. Vpp stays low.
RESADR: 40 <i24 address>
(Version 5)
Indicates the address the target chip is set to after reset for the
reset types that assume a fixed target address. In spec versions
before 5, the reset address was always 0 when used. To maintain
backwards compatibility, the IDRESET command of version 5 and later
resets the RESADR value to 0. The RESADR command must therefore be
used after the IDRESET command.
RESET: 24
Reset the target chip and leave it ready for programming and other
operations. The currently selected reset algorithm will be used.
These algorithms can be selected with the IDRESET command (above).
The program memory space will be selected (see SPPROG command).
IDWRITE: 25 <id>
Select the algorithm for the WRITE operation. IDs of 0-3 are
required for versions 1-9. IDs are optional starting in version
10, but must be reported so by the GETCAP command. Valid values of
ID are:
0: None. Dummy algorithm that performs no action.
1: Generic 16F. This algorithm fully implements all writes to
PICs like the 16F877.
2: 12F6. Fully implements all writes to PICs like 12F629, 12F675.
3 (Version 5): For 12 bit core devices.
4 (Version 11, optional): For dsPIC devices. If the W30PGM command
is implemented, then it must be used to write to ordinary
program memory. In that case, this write algorithm is
undefined for ordinary program memory and need not be
implemented for that case.
5 (Version 12, optional): For 16F87xA devices. These require 8
words per BEGIN ERASE/PROGRAMMING CYCLE command (8), the BEGIN
PROGRAMMING ONLY CYCLE command (24) requires END PROGRAMMING
(23), plus some other differences from the generic algorithm
used for ID 1.
6 (Version 13, optional): For 16F716 devices. Writes are done with
BEGIN PROGRAMMING command (24) and terminated with END
PROGRAMMING (9).
7 (Version 14, optional): For 16F688 and related devices. These
chips have a multi-word write buffer. The write buffer is
loaded, then the entire buffer is written in one programming
operation. WBUFSZ value must be correctly set. Uses BEGIN
PROGRAMMING INTERNALLY TIMED command (8) to perform write.
8 (Version 14, optional): For 18F2520 and related. For normal
program memory or EEPROM only. Writes must be performed on
entire write buffers at a time. Results are undefined if a
write sequence does not start at the start of a write buffer
and end at the end of a write buffer. Write buffer sizes for
these target chips vary and are specified in the configuration
9 (Version 16, optional): for 16F87/88. Writes are done with BEGIN
PROGRAMMING (24) and terminated with END PROGRAMMING (23).
Writes must be done on entire write buffer at a time. WBUFSZ
must be set correctly.
10 (Version 17, optional): for 16F77 and related. Writes are done
with BEGIN PROGRAMMING (8) and terminated with END PROGRAMMING
(14).
11 (Version 23, optional): for 16F88x. Writes are done with BEGIN
PROGRAMMING (24) and terminated with END PROGRAMMING (10).
12 (Version 29, optional): for 16F182x, and probably other enhanced
PIC 16. Uses RESET ADDRESS (22) instead of resetting the
device to force the address to 0. Assumes the normal program
memory region is 0000-7FFFh, and the config region is
8000-FFFFh.
13 (Version 29, optional): For 16F1xxxxx parts that use the
programming protocol with 8 bits opcodes, like the 16F15313.
All pervious PIC 16 used roughly the same protocol with 6 bit
opcodes.
14 (Version 29, optional): For 16F183xx and related. The used are
LOAD DATA FOR NVM (2), LOAD DATA FOR NVM and increment adr
(34), BEGIN EXTERNALLY TIMED PROGRAMMING (24), END PROGRAMMING
(10), BEGIN INTERNALLY TIME PROGRAMMING (8), LOAD PC ADDRESS
(29), and INCREMENT ADDRESS (6).
15 (Version 29, optional): For 18Fxxxx that use the programming
protocol with 8 bit opcodes and data is passed in a 24 bit
word, like 18F25Q10. Similar to write algorithm 13, but for
the PIC 18 architecture, and some different opcode values.
WBUFSZ: 63 <size>
(Version 14, optional)
Indicates the size of the target chip write buffer in address
units. This value was not needed for any write operations
supported before spec version 14. For backwards compatibility,
this value is set to 1 by the IDWRITE command. The WBUFSZ command
must therefore be used after the IDWRITE command.
WBUFEN: 62 <i24 address>
(Version 16, optional)
Indicate the last address covered by the write buffer. The write
buffer is assumed to apply if the WBUFSZ value is greater than 1
and the address of a write is less than or equal to the WBUFEN
value.
The write buffer address extent is inherently known to some write
algorithms, in which case this value may be ignored. This value is
irrelevant unless WBUFSZ is set to greater than 1.
If this command is implemented then it must be issued after the
write ID is set and before any attempt to perform a write. Since
this command must be used when present and it was first defined in
specification version 16, any firmware implementing this command
must not claim compatibility with previous versions of the spec.
IDREAD: 26 <id>
Select the algorithm for the READ operation. IDs of 0-3 are
required for versions 1-9. IDs are optional starting in version
10, but must be reported so by the GETCAP command. Valid values of
ID are:
0: None. Dummy algorithm that performs no action.
1: Generic 16F. For parts like 16F877.
2: Generic 18F. For parts like 18F452. This version only needs
to work on program memory space. If read ID 5 is implemented,
this can be the same routine.
3 (Version 5): For 12 bit core devices.
4 (Version 11, optional): For dsPIC devices.
5 (Version 14, optional): For generic 18F parts. Unlike read ID
2, this version must work for both program memory space and
EEPROM space.
6 (Version 29, optional): For 16F182x and probably other enhanced
PIC 16.
7 (Version 29, optional): For 16F PICs that use 8 bit programming
commands, like the 16F15356.
8 (Version 29, optional): For 16F183xx and related.
9 (Version 29, optional): For PIC 18 that use the 8 bit
programming commands, like 18F25Q10.
TEST1: 27
(Optional at version 10 or higher)
This command is reserved for debugging firmware. It is re-written
as needed, and therefore has no fixed definition. It is not
intended for normal operation, and its results are undefined.
ADR: 28 <i24 address>
Set the address for the next target operation.
READ: 29
RSP: <i16 data>
Read from the target chip at the current address and increment the
address by 1. Two bytes of data are always returned. If the
amount of data at one address is less than 16 bits, then the data
is justified in the low bits and the unused high bits are set to 0.
READ64: 69
RSP: <word 0> ... <word 63>
Read the 64 data words from the target chip starting at the current
address and increment the address by 64. A 16 bit word is returned
for each address. If the amount of data at one address is less
than 16 bits, then the data is justified in the low bits and the
unused high bits are set to 0. The data returned by this command
is undefined if the starting address is not a multiple of 64.
The intent of this command is to allow for faster readbacks with
communication links that have high bandwidth but significant round
trip response overhead, such as the USB. The additional possible
unused bits cause no harm when the communication bandwidth is
significantly higher than the readback speed from the target PIC,
but the large chunk of return data minimizes the number of
request/response cycles and their corresponding latency.
WRITE: 30 <i16 data>
Write to the target at the current address and then increment the
address by 1. The low bits of the 16 bit data word are used when
the amount of data at one address is less than 16 bits.
Some write algorithms require whole WBUFSZ words to be written at a
time. The write may not be performed until the last word in the
block is written. Any such restriction for a particular write
algorithm is noted in the IDWRITE command description.
WRITE8: 60 <data 0> ... <data 7>
(Version 14, optional)
Write 8 words at a time. Only the low 8 bits of each word are
transferred, and any remaining upper bits are assumed to be 1. This
command is intended as a more efficient way of transferring data to
the programmer when the write data is only 8 bits wide. 8 data
bytes can be sent with 9 communcation bytes using the WRITE8
command, whereas 24 communications bytes would be required by
successive WRITE commands. If implemented, this command always
functions identically to 8 successive WRITE commands with the upper
byte of each data word set to all 1s.
TPROG: 31 <ticks>
Sets the programming write cycle delay time in number of
programmer internal clock ticks. The clock tick period is 200 us
unless the GETTICK command is implemented.
This wait time is automatically enforced on a WRITE command.
Multiple WRITE commands can therefore be issued sequentially, and
the appropriate waits will be automatically inserted.
Note that while this command is required and must therefore
always be read by a programmer, its value is irrelevant when the
TPROGF command is implemented.
TPROGF: 83 <ticks16>
(Version 29, optional)
Sets the "fast" proramming wait time. This allows describing
programming wait times with a finer resolution than the TPROG
command may allow. If the program wait time is too long for
65534 fast ticks, then this value must be set to 65535.
The host must set wait times with both TPROG and TPROGF when
implemented. The programmer can chose which to use.
When this command is implemented, the FTICKF command must also be
implemented. That command provides the frequency of the clock of
which ticks will be counted.
The TICKS16 is the 16 bit total number of ticks to wait.
FTICKF: 84
RSP: freq32
(Version 29, optional, required if TPROGF implemented)
Gets the frequency of ticks used by the TPROGF command. This
command is required if TPROGF is implemented.
FREQ32 is the frequency as a 32 bit unsigned integer in Hz
divided by 256 (shifted right 8 bits). For example, a FREQ32
value of 00012345h represents a frequency of 1234500h, which is
19.088640 MHz. The tick period is therefore about 52.39 ns.
SPPROG: 32
Select the program memory space for subsequent read and write
operations. This is the default after a RESET command.
SPDATA: 33
Select the data memory space (data EEPROM) for subsequent read and
write operations.
INCADR: 34
Increment the target address of the next operation by 1.
ADRINV: 35
Invalidate the firmware copy of the current address that the target
chip is set to. The address will be deliberately set in the target
chip before the next operation that assumes an address.
The firmware automatically tracks the target chip address when high
level read/write operations are performed. However, the firmware
can not track the target chip address when the host directly
performs low level operations (SEND1, RECV1, etc) on the target
chip. The ADRINV command should be issued by the host after
performing low level operations that modify the current address in
the target chip.
PAN18: 36 <data 0> ... <data 7>
(required in versions 1-9, optional from version 10 on)
Write one buffer of 8 bytes to a program memory panel. This is a
specialized command that must only be used if the target chip
supports 8 byte panel writes (like the 18Fxx2 for example), and the
chip is properly set up. The write will start at the current
target address, which must be 8-byte aligned (low 3 bits zero).
The desired target address will be advanced by 8 by this command.
Successive 8 byte panel writes can therefore be performed with only
a stream of PAN18 commands. The wait time set by the TPROG command
will be automatically inserted to allow the write operation to
complete.
This command starts a buffered write, writes the data to the write
buffer, and then performs the write. It can only be used if the
write buffer is exactly 8 bytes in size. If not then the commands
PANST, PAN8NW, and PAN8WR must be used.
RBYTE8: 37
RSP: <data 0> ... <data 7>
Read 8 consecutive words and return their low bytes. The first
byte will be read from the desired target address when the command
is run. The desired target address will be left at the next word
after the last one that was read.
The purpose of this command is to provide a faster means of reading
large memory areas when the target word size is 8 bits or less.
WRITING: 38
Indicate that the target chip is being written to. This causes the
status LED to indicating writing for at least the next 250 ms. If
multiple WRITING commands are issued less than 250 ms apart, then
the status LED will indicate the target is being written to
continuously.
The WRITING state is indicated automatically when higher level
write commands are used. However, low level commands (like SEND
and RECV) can be used to write to the target. The LED is not set
to WRITING status by these commands since they can be used for
other purposes. The WRITING command provides a means to set the
LED to WRITING status explicitly.
CHKCMD: 41 <cmd>
RSP: <data>
(Version 5)
Checks whether a particular command is available. CMD is the
command opcode inquiring about, and DATA is returned 0 if the
command is not available and 1 if it is.
The intent of this command is to provide an easier mechanism for
host software to determine whether a particular command may be used
than to have a list of allowable commands for each version as
reported by the CVLO and CVHI return values of the FWINFO command.
Some commands are optional, and the CHKCMD command is the only
means to determine their availability.
It is recommended that the CHKCMD be used to determine the
avaiability of all commands if the firmware reports compatibility
with spec version 5 or higher, even though some commands must
always be present at certain spec versions.
GETPWR: 42
RSP: <i16 millivolts>
(Version 6, optional)
Get the internal voltage used to power the processor running the
control firmware. This is not the target chip Vdd level.
The return argument is an unsigned 16 bit value in units of
millivolts. Note that units of millivolts is used for
communications purposes only, and does not imply the actual
resolution or accuracy. Consult the documentation for the
particular firmware or unit for accuracy and resolution values.
GETVDD: 43
RSP: <i16 millivolts>
(Version 6, optional)
Get the measured target chip Vdd (power) voltage.
The return argument is an unsigned 16 bit value in units of
millivolts. Note that units of millivolts is used for
communications purposes only, and does not imply the actual
resolution or accuracy. Consult the documentation for the
particular firmware or unit for accuracy and resolution values.
GETVPP: 44
RSP: <i16 millivolts>
(Version 6, optional)
Get the measured target chip Vpp (programming) voltage.
The return argument is an unsigned 16 bit value in units of
millivolts. Note that units of millivolts is used for
communications purposes only, and does not imply the actual
resolution or accuracy. Consult the documentation for the
particular firmware or unit for accuracy and resolution values.
WAITCHK: 45
RSP: <flags>
(Version 7, optional)
Wait for any currently scheduled wait interval to elapse and
check for errors.
The returned FLAGS byte is zero when no errors or exception
conditions occurred. The meaning of the individual bits are:
7 6 5 4 3 2 1 0
-----------------------------------------------------------------
| | | | | | | | |
| X | X | X | X | VPPH | VPPL | VDDH | VDDL |
| | | | | | | | |
-----------------------------------------------------------------
VDDL is set if the target chip Vdd voltage was still too low
when the wait timeout expired.
VDDH is set if the target chip Vdd voltage was still too high
when the wait timeout expired.
VPPL is set if the target chip Vpp voltage was still too low
when the wait timeout expired.
VPPH is set if the target chip Vpp voltage was still too high
when the wait timeout expired.
X indicates a reserved bit. These are sent as 0 in this version
of the spec, but may be defined in future versions.
GETBUTT: 46
RSP: <npress>
(Version 8, optional)
Returns the number of user button presses since power up modulo
256. This value is only reset to 0 by power down. It is
uneffected by all other commands, the host input stream timeout,
and the like.
APPLED: 47 <bri> <phase 1 5 ms> <phase 2 5 ms>
(Version 8, optional)
Sets the display on the "App" LED. The LED will alternate between
two display phases. The brightness and duration of each phase can
be set. This command resets the display to the beginning of phase
1.
BRI contains the 0-15 brightness for phase 1 in the low 4 bits and
the 0-15 brightness for phase 2 in the high 4 bits. Brightness of
0 is completely off, and 15 is maximum.
The remaining two parameter bytes set the time duration for phase 1
and phase 2 respsectively. Each is an unsigned byte in units of
5 ms.
If it is not desired to have the LED flash, then set both
brightness values the same. The phase times become irrelevant in
that case.
The "App" LED is physically closely associated with the user button
on the target unit when both are present. The App LED can be used
as a prompt or confirmation of user button activity.
RUN: 48 <Vdd>
(Version 8, optional)
Reset the target PIC and then allow it to run. After the reset,
the Vpp (MCLR), PGC, and PGD lines are set to high impedence, and
it is up to the target ciruit to drive them appropriately for the
application. If the VDD parameter byte is 0, then the target Vdd
line is also set to high impedence. If the VDD parameter byte is
1-250, the target Vdd line is driven to that value times 24 mV. In
other words, VDD of 0-250 maps to 0.0-6.0 volts, except that VDD of
0 is a special case where the target Vdd line is not driven at all.
The host timeout is disabled by this command, and re-enabled when
the next command is received. This means an application can enter
RUN mode and exit without the target system being automatically
reset 5 seconds later.
HIGHZ: 49
(Version 9)
Set all the target PIC lines to high impedence to the extent
possible. If the programmer is not capable of releasing a line,
then it should be set low. In any case, the programmer must not
supply power or a high Vpp level.
In general, in-circuit programmers can set their lines to high
impedence since they are designed to operate with a wide range of
possible target circuits. In-socket programmers generally
passively pull lines down to turn "off" the target chip.
The intent of this command is to make the programmer appear not
present to the target chip to the extent possible. This is also
the power up state of the programmer, and the state it
automatically reverts to on a host input stream timout. It is
always permissible to disconnect the target circuit or chip from
the programmer in this state.
Note that this command differs somewhat from the RUN 0 command.
First, the RUN command is only present if the programmer can
release all the lines. Second, the RUN command always makes sure
the target chip is in a reset condition before entering the
requested state. The HIGHZ command just releases all lines to the
extent it can from whatever state they were in.
The Embed Inc PIC programmers react to the HIGHZ command in the
following ways:
| EasyProg | ProProg
-----|----------------------|-----------------------
Vpp | 700 Ohms to ground | > 1 MOhm
Vdd | 360 Ohms to ground | > 10 kOhms to ground
PGC | 2 kOhms to ground | >= 190 kOhms to ground
PGD | 2 kOhms to ground | >= 19 kOhms to ground
NTOUT: 50
(Version 9)
Disable the command stream timeout (See Command Stream Timeout
section earlier in this document). The timeout is automatically
re-enabled at the start of each command (whenever an ACK byte is
sent to the host). This allows a program to exit but leave the
programmer in an unusual state indefinitely. Since every command
implicitly re-enables the host timeout, this must be the last
command issued before exiting a program that intends to leave the
programmer in a non-default state.
GETCAP: 51 <capability ID> <data>
RSP: <capability level>
(Version 10, optional)
This command allows the host to inquire about specific capabilities
of the programmer unit. Certain programmer capabilities were
implied in previous spec versions, such as variable Vdd output,
that might be burdensome to some programmer implementations. Some
of these restrictions are relaxed in specification version 10. The
GETCAP command is not required, but the capabilities listed as
default must then be implemented. If any default capabilities are
not implemented, then the programmer must otherwise support
specification version 10 at minimum and must implement the GETCAP
command.
A response byte value of 0 always indicates the default capability
level. This is also the implied capability level when the GETCAP
command is not implemented. The meanings of response byte values
1-255 depend on the capability that was inquired about.
All possible values of CAPABILITY ID are legal even though many are
not implemented. The programmer must always return 0 for any
unimplmented capability ID. Since 0 indicates the default
capability, this allows new capabilities to be added but older
firmware to still be compatible. The default for any such new
capabilities will be "not implemented". Old firmware will
therefore automatically report any newly defined capabilities as
not being implemented.
The meaning of the optional data byte following the capability ID
is dependent on the capability ID. This byte is ignored for
unimplemented capability IDs since 0 is always returned.
The capability IDs and the meaning of their response bytes are:
0 0: Variable Vdd
Responses are:
0 Variable Vdd from 0 to 6 volts is implemented.
1 Variable Vdd is not implemented. The VDDVALS and VDD
commands are ignored if present. If the commands
VDDLOW and VDDHIGH are implemented, they function as
VDDNORM.
0 1: Fixed Vdd level
The fixed Vdd level if variable Vdd is not implemented. This
value has no meaning unless the response to 0,0 is 1, meaning
the programmer implements fixed Vdd. The 0-255 return value
is the voltage in the range of 0 to 6 volts. This is the same
encoding as used by the VDD command.
1 <reset ID>: Reset IDs
The data byte is the reset algorithm ID. Note that this is
not the same as the data byte passed to the IDRESET command
starting with spec version 18. Responses are:
0 Indicates implemented for reset IDs 0-3, unimplemented
for all others. Since IDs 0-2 are required, this
value is always returned for data bytes 0-2.
1 Indicates unimplemented for reset IDs 0-3, implemented
for all others.
2 <write ID>: Write IDs
The data byte is the same as the data byte of an IDWRITE
command. Responses are:
0 Indicates implemented for write IDs 0-3, unimplemented
for all others.
1 Indicates unimplemented for write IDs 0-3, implemented
for all others.
3 <read ID>: Read IDs
The data byte is the same as the data byte of an IDREAD
command. Responses are:
0 Indicates implemented for read IDs 0-3, unimplemented
for all others.
1 Indicates unimplemented for read IDs 0-3, implemented
for all others.
4 0: Vpp minimum
Inquires the minimum Vpp level (when enabled) the
programmer can be set to. Responses are:
0 Vpp level is fixed at 13V and can not be changed.
1-255 Minimum Vpp level on 0-20V scale. This value is in
the same units as the parameter to the VPP command.
4 1: Vpp maximum
Inquires the maximum Vpp level (when enabled) the
programmer can be set to. Responses are:
0 Vpp level is fixed at 13V and can not be changed.
1-255 Maximum Vpp level on 0-20V scale. This value is in
the same units as the parameter to the VPP command.
W30PGM: 56 <word24 0> <word24 1> <word24 2> <word24 3>
(Version 11, optional)
Write 4 program memory words to a dsPIC target. This is a
specialized command that must only be used if the target chip is a
dsPIC, program memory space is selected, and the target is
otherwise set up and in programming mode.
The write will start at the current target address, which must be a
multiple of 8 (low 3 address bits zero). The current address will
be updated to the next address after the last written by this
command. The address will be advanced by 8 since there are two
addresses per program memory word. The first address of a program
memory word refers to the low 16 bits, and the second to the high 8
bits.
This command must always be used to write an entire block of WBUFSZ
addresses. Note that this is WBUFSZ/2 program memory words since
each 24 bit program memory word occupies two addresses. No other
commands are allowed during the writing of a whole block. The
entire block must be aligned starting at a multiple of WBUFSZ
addresses. The first WBUFSZ/8 - 1 commands of the block only load
the program memory write latches. The last command of the block
loads the write latches with the data words of that command too,
but also performs the actual write of the entire block of WBUFSZ/2
words to program memory. The results of this command are undefined
if it is not used WBUFSZ/8 times in succession to program a block
of WBUFSZ/2 words as described.
The program operation does not perform an erase, and can only set 1
bits to 0. Therefore it is possible to modify only part of a block
of 32 words by setting all the bits to remain unchanged to 1. This
also means that it is up to the application to ensure a block is
erased before programming if attempting to load arbitrary values
into the block.
If this command and write ID 4 are both implemented, then write ID
4 is not required to function correctly for ordinary program
memory. An application must therefore check for the presence of
this command and use it exclusively to write to program memory when
it is implemented, whether write ID 4 is implemented or not.
TEST2: 57 <dat>
RSP: <dat0> <dat1> <dat2> <dat3>
(Version 11, optional)
This command is reserved for debugging firmware. It is re-written
as needed, and therefore has no fixed definition. It is not
intended for normal operation, and its results are undefined, other
than it must accept one byte of data and return 4 bytes of data.
R30PGM: 58
RSP: :<word24 0> <word24 1>
(Version 11, optional)
Read 2 program memory words from a dsPIC target. This is a
specialized command that must only be used if the target chip is a
dsPIC, program memory space is selected, and the target is
otherwise set up and in programming mode.
The read will start at the current address, which must a multiple
of 4 (low 2 address bits zero). The current address will be
updated to the next address after the last read by this command.
The address will be advanced by 4 since there are two addresses per
program memory word. The first address of a program memory word
refers to the low 16 bits, and the second to the high 8 bits.
If this command and read ID 4 are both implemented, then read ID 4
is not required to function correctly for ordinary program memory.
An application must therefore check for the presence of this
command and use it exclusively to read from program memory when it
is implemented, whether read ID 4 is implemented or not.
DATADR: 59 <adr24>
(Version 11, optional)
Define a starting address for data EEPROM. For most PIC types, the
method for accessing the first and subsequent locations of data
EEPROM memory are fixed. This command is not needed for those PIC
types, and may be ignored by the programmer in those cases.
Data EEPROM is really a separate memory that is in a separate
address space on some PICs, and mapped to an existing address space
on others. The ADR24 parameter is meant to indicate the "starting
address", although that may be interpreted differently for
different PIC types.
The meaning of the ADR24 parameter for each of the PIC types that
require this command be used is given below. If a PIC type is not
listed, then this command is not needed for that PIC type, and may
be ignored by the programmer.
dsPIC:
ADR24 is the program space address where the first EEPROM word
is mapped. The last EEPROM word is always mapped to 7FFFFEh,
and the starting address depends on the number of EEPROM words
implemented. ADR24 should be set to 800000h for PICs that
have no data EEPROM.
12 bit core:
Program memory address where the start of non-volatile data
memory is mapped. This only needs to be set for devices that
have non-volatile data memory.
Enhanced 14 bit core:
Program memory address where the start of non-volatile data
memory is mapped. This only needs to be set for devices that
have non-volatile data memory.
There is no guaranteed default value. This command must be used
for any of the PIC types listed above, unless otherwise noted.
NAMESET: 66 <len> <char1> ... <charN>
(Version 20, optional)
Set the non-volatile user assigned name for this programmer. The
name is not used by the programer except to report it back when
asked. This name is intended to distinguish multiple programmers
connected to a system or a common bus. It is therefore strongly
recommended that each unit be given a unique name.
LEN indicates the number of characters in the name, with exactly
that many character bytes following. All values of LEN (0-255) are
legal, and must always be followed by exactly LEN character bytes.
Programmers silently discard name characters past what they can
store, although the indicated number of characters must always be
read from the command stream. If this command is implemented, the
programmer must store at least the first 15 name characters (the
name may not be truncated to less than 15 characters by the
programmer).
It may be necessary to issue the REBOOT command if the programmer
name is cached by the operating system. This is the case, for
example, with the USBProg programmer communicating over the USB.
NAMEGET: 67
RSP: <len> <char1> ... <charN>
(Version 20, optional)
Return the non-volatile user assigned name for this programmer.
The return bytes have the same format as the data bytes for the
NAMESET command. Only the stored name is returned, regardless of
how many characters were sent with the NAMESET command.
REBOOT: 68
(Version 21, optional)
Completely restart the control processor of the programmer.
Depending on the I/O connection type to the programmer, it may be
necessary to re-establish communication. For example, if the
programmer is connected via the USB, then the REBOOT command will
make it appear as if it was unplugged then plugged back into the
USB. This will cause all existing connections to it to be broken,
and the application must establish a new connection for further
communication. Programmers connected via TCP will act similarly,
but RS-232 connections will stay open since the host operating
system can not detect the programmer reboot.
The purpose of this command is to force the operating system to
treat the programmer as a new device. This is necessary if any
setting in the programmer was changed that is cached by the
operating system. This is the case, for example, with the non-
volatile user assigned name string of the USBProg programmer when
connected via the USB.
TESTGET: 71
RSP: <test mode ID>
(Version 29, optional)
Returns the ID of the current test mode. This command is required
if the TESTSET command is implemented. See the TESTSET command
description for details on the test mode.
TESTSET: 72 <test mode ID>
(Version 29, optional)
Sets the new test mode according to the ID. Test modes are
optional operating modes that may be useful during production, and
for diagnosing problems. Test mode 255 is always normal end user
operation. Test modes 0-254 are defined separately by each
programmer type. The test mode setting may be non-volatile and may
require a REBOOT to take effect. This is specific to each
programmer type.
If the TESTSET command is implemented, then the TESTGET command
must also be implemented. If TESTSET is not implemented, then the
unit is permanently in end user operating mode. In that case
TESTGET may be implemented, but if so it must always return 255.
The test modes of the Embed Inc programmers are listed below. Any
Embed Inc programmer not listed does not have optional test modes
and therefore may not implement the TESTSET command. Operation is
undefined if a undefined test mode is set. Note that 255 is the
only test mode guaranteed to be defined for all programmers. The
test modes of the Embed Inc programmers are:
LProg
The test mode is non-volatile. A new setting does not take
effect until the next power up or REBOOT command. The default
test mode specified in the HEX file is 255. The test mode does
not effect USB communication.
0: Serial communication mode. The TX and RX lines are the raw
micocontroller UART signals. The serial communication
protocol described in this document is implemented except
that the baud rate is 19,200 instead of 115,200. The RX
line is a CMOS input and should be externally driven so that
it does not float.
255: Normal operating mode. The TX and RX lines are both held
low and implement no communication function. Nothing should
be connected to these lines.
EECON1: 73 adr
EEADR: 74 adr
EEADRH: 75 adr
EEDATA: 76 adr
VISI: 77 adr
TBLPAG: 78 adr
NVMCON: 79 adr
NVMKEY: 80 adr
NVMADR: 81 adr
NVMADRU: 82 adr
(Version 29, optional)
Each of these commands defines the address in the target of the
special function register indicated by the command name. These may
not be relevant to all PIC types. These special function registers
can be at different addresses depending on the exact PIC model.
ADR is a 16 bit unsigned integer.
These values are reset to their defaults whenever the reset
algorithm ID is set.
The defaults are:
From original PIC 18:
EECON1 FA6h
EEADR FA8h
EEADRH FAAh
EEDATA FA8h
From original dsPIC:
VISI 0784h
TBLPAG 0032h
NVMCON 0760h
NVMKEY 0766h
NVMADR 0762h
NVMADRU 0764h
SENDSER: 85 <n-1> <dat> ... <dat>
(Version 29, optional)
Sends bytes over the separate serial port of the programmer. N is
the number of bytes to send. Exactly N DAT bytes follow the <n-1>
byte. All the DAT bytes will be transmitted over the serial port
in the same order as in this command.
Programmers are not required to have a separate serial port. This
command is only allowed to be implemented when the programmer has a
serial port that is not being used to implement this command
protocol.
The serial port protocol is 115.2 kBaud, 8 data bits, 1 stop bit,
no parity bit.
RECVSER: 86
RSP: <n> <dat> ... <dat>
(Version 29, optional)
Gets any bytes received over the separate serial port of the
programmer since the last RECVSER command. N is the number of data
bytes, followed by exactly that number of bytes.
Programmers are not required to have a separate serial port. This
command is only allowed to be implemented when the programmer has a
serial port that is not being used to implement this command
protocol.
The serial port protocol is 115.2 kBaud, 8 data bits, 1 stop bit,
no parity bit.
SEND8M: 87 <data>
(Version 29, optional)
Sends the 8 bits of DATA to the target in most to least significant
byte order.
SEND24M: 88 <i24 data>
(Version 29, optional)
Sends the 24 bits of DATA to the target in most to least
significant byte order.
RECV24M: 89
RSP: <i24 data>
(Version 29, optional)
Reads 24 bits from the target in most to least significant byte
order.
Application specific commands: 240 - 255
(Version 27, optional)
These 16 commands are specifically not defined in this
specification. Their purpose is to allow access to custom hardware
features. Of course, general purpose software will not use these
features nor issue these commands. These features may have nothing
to do with PIC programming, and may control other hardware
implemented in the same device.
All software that issues these commands must first verify they are
implemented by using the CHKCMD command, which must be implemented.
It is strongly recommended that custom software verify it is
communicating with the expected device before using these commands.
Each custom device should have a unique signature as reported by
the FWINFO and FWINFO2 commands.
While the meaning of these commands is up to the custom
implementation, the same overall framework of commands and
responses must still be followed. If flow control is implemented
at the protocol level, then the ACK byte must be sent by the device
after it has read the opcode byte. Response bytes, if any, must be
sent before the response bytes of any other command.
If the command response is variable length, then a particular
format must be followed. The fixed bytes must be first, followed
by a length byte that indicates how many bytes follow. Since the
length byte follows the fixed bytes, the length byte is always at a
known fixed offset into the response byte stream. This also means
that there may be 0 to 255 bytes following the length byte,
depending on the value of the length byte. There may only be at
most one such variable length field in each reponse.