Admin: Created page with "

  BIP: ?  Title: Abstract JTAG Protocol  Author: Luke Dashjr   Status: Draft  Type: Standards Track  Created: 14-07-2012

==Abstract== ==S..."

2019-04-08T02:41:28Z

Created page with "<pre> BIP: ? Title: Abstract JTAG Protocol Author: Luke Dashjr <luke+bipmhbp@dashjr.org> Status: Draft Type: Standards Track Created: 14-07-2012 </pre> ==Abstract== ==S..."

New page

<pre>
BIP: ?
Title: Abstract JTAG Protocol
Author: Luke Dashjr <luke+bipmhbp@dashjr.org>
Status: Draft
Type: Standards Track
Created: 14-07-2012
</pre>

==Abstract==
==Specification==

This protocol is designed to be spoken only over a reliable (including error correction) lower-level protocol, such as USB-Serial or USB-CDC, to a local device.

===Packet Format===
*4 bytes: magic: always <tt>fd414a50</tt>
*1 byte: packet length/type
*N bytes: packet data
*2 bytes: packet data [http://en.wikipedia.org/wiki/BSD_checksum BSD "sum1" checksum]

Packet length/types:
* <tt>00</tt> -- Abort
* <tt>01</tt> to <tt>ef</tt> -- Data packet length (1 to 239 bytes)
* <tt>f0</tt> to <tt>fc</tt> -- Reserved
* <tt>fd</tt> -- Bad packet (command aborted)
* <tt>fe</tt> -- ACK
* <tt>ff</tt> -- End of command

ACK should be sent in response to each 239-byte packet. Bulk data transfers, such as bitstream uploads, should wait until ACK is received before sending more packets.

Checksum must include the complete packet up until the checksum itself; this is not used to prevent corruption (USB already guarantees that), but rather to avoid acting when something foreign sends stuff (possibly intermixed with a real AJP packet). If the checksum does not match, the device should send a "<tt>fd</tt>" packet back and ignore the content.

Note that while Abort packets abort the entire command, but do not guarantee it had no effect.

Anything up to the initial magic is ignored.

===Command Format===
*1 byte: request id
*1 byte: command id
**<tt>Cx</tt> -- JTAG interface commands
**<tt>Dx</tt> -- Replies to JTAG interface commands
**<tt>Ex</tt> -- JAP Controller commands
**<tt>Fx</tt> -- Replies to JAP Controller commands
*1 byte: device number (ignored for some commands)
**<tt>00</tt> is the controller
**<tt>01</tt> to <tt>fe</tt> are JTAG devices
**<tt>ff</tt> for "all JTAG devices"
*1 byte: status (should always be <tt>00</tt> for requests)
**<tt>00</tt> -- success
**<tt>80</tt> -- failure
*N bytes: data

Commands less than 4 bytes should be ignored.
Additional data beyond what is expected should be ignored.

===Commands===
====<tt>c0</tt> -- clock====
Request Data:
* 1 byte: bit field (bitwise OR'd)
** <tt>10</tt> -- return TDI status
** <tt>01</tt> to <tt>03</tt> -- number of clocks to ignore at the end
* N bytes: two bits per clock
** 1 bit: TMS high
** 1 bit: TDO high
Reply Data (only if reading):
* N bytes: one bit per clock
** 1 bit: TDI high

====<tt>c1</tt> -- read/write register====
Note that data is written/read in big endian bit order. This means that the first bit written/read is <tt>80</tt>, then <tt>40</tt>, and so on. If you are not using a multiple of 8 bits, this is still the case; for example, if you read 7 bits all high, you will get <tt>fe</tt>, ''not'' <tt>7f</tt>.

Request Data:
* 1 byte: bit values (bitwise or'd)
** Mode:
*** <tt>00</tt> -- Continue already-started r/w
*** <tt>80</tt> -- Start r/w of DR register
*** <tt>40</tt> -- Start r/w of IR register
** <tt>20</tt> -- Finish r/w
** <tt>10</tt> -- Read+Write (default is Write only)
** <tt>01</tt> to <tt>07</tt> -- Don't do last N bits of data
* N bytes: data to write
Reply Data (may be parallel with request):
* N bytes: data read (only if Read+Write set in request)

====<tt>c2</tt> -- reset====
(No Request or Reply Data)
====<tt>c3</tt> -- run====
Request Data:
* 1 byte: number of iterations to run

====<tt>e0</tt> -- ping====
Device number ignored.
Replies with same data as request
====<tt>e1</tt> -- get device count====
Device number ignored.
May be required before device access.

Reply Data:
* 1 byte: number of devices
* N bytes:
** 1 byte: device id number

====<tt>e2</tt> -- hardware version====
Note: Only expected to work for controller

Reply Data:
* 4 bytes: hardware version (big endian)
* 2 bytes: hardware vendor id authority
** <tt>0000</tt> -- USB
** <tt>ffff</tt> -- Ad-hoc
* 1 byte: length of hardware vendor id
* N bytes: hardware vendor id (binary)
* 1 byte: length of hardware device id
* N bytes: hardware device id (binary)
* 1 byte: length of hardware serial number
* N bytes: hardware serial number (UTF-8)
* 1 byte: length of human-readable hardware model
* N bytes: human-readable hardware model/version string (UTF-8)

====<tt>e3</tt> -- software version====
Note: Only expected to work for controller

Reply Data:
* 4 bytes: software version (big endian)
** <tt>ffffffff</tt> -- Unknown
* 1 byte: length of software-specific unique identifier (git commit?)
* N bytes: software-specific unique identifier
* 1 byte: length of human-readable software name
* N bytes: human-readable hardware model/version string (UTF-8)
* 2 byte: number of AJP features supported

====<tt>e4</tt> -- device capabilities====
Reply Data:
* 2*N bytes: supported capabilities
** <tt>c000</tt> -- JTAG protocol commands
** <tt>e50x</tt> -- watch/poll command, with up to X concurrent watches

====<tt>e5</tt> -- watch/poll====
Request Data:
* 1 byte: how long to watch, in 1/0x10000th of a day (about 1.32 seconds)
** <tt>00</tt> -- cancel watch
** <tt>ff</tt> -- never expire
* 2 bytes: how often to poll, in 1/0x1000000th of a day (about 0.005 seconds)
** <tt>0000</tt> -- constantly poll
** <tt>2d83</tt> -- about once a minute
* N bytes: packets to send
Reply (immediately for all, and whenever results change individually):
* Same as if the packets were received directly

==Examples==

====Reset the command queue====
To reset the command queue, send 243 zero bytes followed by the Abort packet (<tt>fd414a50 00 7052</tt>); this will pad-out any "open" packet, and abort any open command.

It is also advisable to cancel any watch active: <tt>fd414a50 05 00e50000 00 5b9f</tt>

[[Category:Technology]]
[[Category:BIP]]
==See Also on BitcoinWiki==
* [[BitSimple]]
* [[Bitcoin Argentina]]
* [[BitcoinPlus.mx]]
* [[Bitcoincambodia.com]]
* [[Cryptocurrent]]

BIP AbstractJTAGProtocol - Revision history

Admin: Created page with "
BIP: ? Title: Abstract JTAG Protocol Author: Luke Dashjr Status: Draft Type: Standards Track Created: 14-07-2012
==Abstract== ==S..."