The Logic Sniffer's extended SUMP protocol

From DP

Jump to: navigation , search

In addition to the SUMP protocol, the Logic Sniffer also has some custom protocol extensions.


Extended protocol

Self-test command

  • 0x03 - A self test mode can be triggered with 0x03.

0x03 starts a test pattern output on the unbuffered pins. When connected to the buffered pins you can view the pattern with a logic analyzer capture.

This should be expanded with images of the self-test with the Java client update. Maybe a separate section for the self-test overview?

Bit 11 of the flag settings - Internal test pattern mode (supplies data internally)

RLE commands

  • 0x05 - finish now. End the current RLE capture by sampling to the end immediately, then dump the samples

The Verilog core has some bonus rle modes, selected by bits 15:14 of the flags register. The modes are:

  • 0 = Issue <values> & <rle-count> as pairs. Count inclusive of value. Backwards compatible.
  • 1 = Issue <values> & <rle-count> as pairs. Count is -exclusive- of value.
  • 2 = Periodic. <values> reissued approx every 256 <rle-count> fields.
  • 3 = Unlimited. <values> can be followed by unlimited numbers of <rle-counts>.

Default is 0. Higher modes all use exclusive counts. Mode 2 gives robustness & approx. doubles storage of non-changing values. Mode 3 really maxes out storage, but if the initial value is lost, you have problems. Source.

Metadata command

A new command byte is added to the sump protocol: 0x04 - get metadata. In response, the device sends a series of 1-byte keys, followed by data pertaining to that key. The series ends with the key 0x00. The system can be extended with new keys as more data needs to be reported.

Proposed meta data format

The keys are split up into two fields: the upper 3 bits denote the type, and the lower 5 bits denote the token. The token is unique within the type. Thus a 0x01 null-terminated string token is not the same as a 0x01 integer token.

This way a client need only know about the keys it can deal with, while still having a way to skip over the ones it doesn't know -- since the type field denotes a length (or null-terminated field). If more metadata keys get added in the future, clients will just ignore them until support for those keys is added to the application.

This means a client parsing metadata MUST always ignore keys it doesn't know, never give an error message for them.

Type Token Key Description
0 null-terminated string, UTF-8 encoded
0 0x00 not used, key means end of metadata
1 0x01 device name (e.g. "Openbench Logic Sniffer v1.0", "Bus Pirate v3b"
2 0x02 Version of the FPGA firmware
3 0x03 Ancillary version (PIC firmware)
1 32-bit unsigned integer
0 0x20 Number of usable probes
1 0x21 Amount of sample memory available (bytes)
2 0x22 Amount of dynamic memory available (bytes)
3 0x23 Maximum sample rate (hz)
4 0x24 Protocol version (see below)
2 8-bit unsigned integer
0 0x40 Number of usable probes (short)
1 0x41 Protocol version (short)
3-7 unused

There's probably quite a bit more that would be interesting to support (please add to the list).

The protocol version key holds a 4-stage version, one per byte, where the MSB holds the major version number. As of the first release to support this metadata command, the protocol version should be 2. This would be encoded as 0x00000002.

Short commands

The 8bit short commands are an alternative to the 32bit commands for number of probes and version. This saves space on a small systems. Most systems are unlikely to sport more than 256 probes, so there's no reason to store 3 null bytes. A client should support both.

Advanced triggers

Arm advanced trigger (0x0F)

Write trigger select (0x9E)

Write trigger data (0x9F)

Standard protocol

Reset (0x00)

Send it 5 times to make sure you're clear of any partial long commands.

Arm (0x01)

Start capture or arm trigger.

Query ID (0x02)

Returns 1ALS in all known versions.