Embed Inc PIC Programmers Host Protocol Specification Version 29.10, 22 October 2018 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. 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. 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. 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. 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.