BIP AbstractJTAGProtocol

This page describes a BIP (Bitcoin Improvement Proposal). Please see BIP 2 for more information about BIPs and creating them. Please do not just create a wiki page.

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

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 fd414a50
• 1 byte: packet length/type
• N bytes: packet data
• 4 bytes: packet data CRC32 (omit for Abort and Bad packet)

Packet length/types:

• 00 -- Abort
• 01 to ef -- Data packet length (1 to 239 bytes)
• f0 to fc -- Reserved
• fd -- Bad packet (command aborted)
• fe -- ACK
• ff -- End of command

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

CRC32 must include the complete packet up until the CRC32 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 CRC32 does not match, the device should send a "fd" 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
  • Cx -- JTAG interface commands (potentially dangerous)
  • Dx -- Replies to JTAG interface commands
  • Ex -- Informational commands
  • Fx -- Replies to Informational commands
• 1 byte: device number (ignored for some commands)
  • 00 is the controller
  • 01 to fe are JTAG devices
  • ff for "all JTAG devices"
• 1 byte: status (should always be 00 for requests)
  • 00 -- success
  • 80 -- failure
• N bytes: data

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

Commands

c0 -- clock

Request Data:

• 1 byte: bit values (bitwise or'd)
  • 01 -- TDO high
  • 02 -- TMS high

Reply Data:

• 1 byte: TDI status
  • 00 -- Low
  • 01 -- High

c1 -- read/write register

Request Data:

• 1 byte: bit values (bitwise or'd)
  • 80 -- Use IR register (default is DR)
  • 40 -- Read+Write (default is Write only)
  • 01 to 07 -- Don't send 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)

c2 -- reset

(No Request or Reply Data)

c3 -- run

(No Request or Reply Data)

c8 -- watch/poll

Request Data:

• 1 byte: how long to watch, in seconds
  • 00 -- cancel watch
  • ff -- never expire
• N bytes: packets to send

Reply (immediately, and whenever results change):

• Same as if the packets were received directly

e0 -- ping

Device number ignored. Replies with same data as request

e1 -- get JTAG device count

Device number ignored. Reply:

• 1 byte: number of JTAG devices

e2 -- hardware version

Note: Only expected to work for controller

Reply Data:

• 4 bytes: hardware version (big endian)
• 2 bytes: hardware vendor id authority
  • 0000 -- USB
  • ffff -- 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)

e3 -- software version

Note: Only expected to work for controller

Reply Data:

• 4 bytes: software version (big endian)
• 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
• 2*N bytes: AJP features supported
  • c800 -- watch/poll command

Examples

Reset the command queue

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