Packet Presenter
Packet Presenter Overview
Using the ACTIVE-Pro application, it is normal for users to debug communication that is being transmitted between ICs or system components. This debugging can be performed by viewing the waveforms on the screen, or by viewing decoded bus traffic for the various types of busses. For example users can see the voltage versus time waveforms of an ASYNC bus Tx and Rx lines, or decode the waveform into a byte stream using the standard bus definition (ASYNC for example) that is then displayed in text in-line with the waveform.
The PacketPresenter™ feature runs alongside of the existing bus decoders of the ACTIVE-Pro. The PacketPresenter™ takes the output of raw binary data from the bus decoder and parses the stream according to users PacketPresenter Definition File for the intent of displaying the communications in easily understood graphical displays. The resulting packets are then displayed in a waveline below the bus raw bus decoded data waveforms.
Protocols are defined by clicking the Edit Packet Format Button and is called a PacketPresenter Definition, which specifies the fields within the protocol and how to display that information on the screen. It is intended to be generic enough that customers can create their own protocol decoders for their own custom bus types. Initially, all bus types use a generic PacketPresenter file to display the bus data for that bus. You can then create and customize your own PacketPresenter file for any bus.
It is assumed that each PacketPresenter Definition will correspond to one single bus type, and that the incoming bytes from that bus will be inputs for the decoding process. This steam of data is called an incoming Data Stream and it is handled by a Protocol Processor. Each Protocol Processor takes a single incoming Data Stream that is broken into Packets, parsed into Fields and either displayed as a field on the screen, ignored, and/or sent to a new Protocol for further processing (as in an N layer protocol).
Each Protocol Processor defines how to break the stream into Packets, and how to break the Packets into Fields. These Fields can then be displayed or sent to another Data Stream for further processing.
Setting Up the PacketPresenter
To use the Packet Presenter on a Hardware Bus Decoder, select the bus type you want to use in the Inputs Tab (I2c, SPI, UART…). Once chosen, a generic Packet Format is created that will output the raw data in human readable form. You can then click the Edit Packet Format Button to customize the packet definition and you will see the editor window below.
You can load an existing Packet Definition by clicking the Import button. You can save the current Packet Definition by clicking the Export Button. To bring up this web page, click on the Help Button. Click the Save Button to save and re-process the bus using the new Packet Definition.
Viewing the PacketPresenter Output
The PacketPresenter output is shown in a waveline below the bus decode waveline and has the title that is defined in the PROTOCOL section of the Packet Definition.
PacketPresenter to Waveform Association using Cursors
The PacketPresenter output and waveform display are synchronized using the Cursors. This feature allows you to correlate what is shown in the PacketPresenter window to the actual waveform on the logic analyzer that created that packet.
You can place the cursors using the PacketPresenter window by using the left and right mouse buttons. Place the mouse over the packet you want to place the cursor on and click the left or right mouse button. The cursors are placed at the beginning of the packets. The resulting difference between cursors is shown in the Measurement Window.
Conversely, if you place the X1 and X2 cursor in the Waveform display using the Cursors Bar, the cursors are moved in the PacketPresenter window and it is scrolled to show that location in the packet list.
PacketPresenter Definition File Format
Each PacketPresenter Definition file defines how the incoming data stream is represented in the PacketPresenter screen of the ACTIVE-Pro application. These PacketPresenter Definition files are in text format and are easily created using a simple text editor.
Each bus defined in the ACTIVE-Pro application can have a different PacketPresenter Definition File.
The intent of the PacketPresenter is to produce a series of 2 dimensional arrays of labels and values to be displayed as below by the user interface.
Command = 45, Length = 2, Address = 84DF, Data = 34
Command = Read RSSI, Value = 14.34
Command = 23, Setting = Power Amp On
It is the PacketPresenter Definition File that defines how the data is to be parsed and displayed.
Comments in the PacketPresenter Definition File
Comments are started with // and go until the end of the line.
Constants in the PacketPresenter Definition File
Constants are fixed numbers anywhere in the file. These constants can be expressed as decimal, hex, or binary using suffixes after the value. Decimal has no suffix. Hex uses the suffix “h”. Binary uses the suffix “b”.
So,
16 = 10h = 10000b
244 = F4h = 11110100b
Gain and offset values used in the Fields section are always in decimal and can contain decimal places.
PacketPresenter Definition File Sections
Each PacketPresenter Definition File has the following syntax that separates the file into sections that correspond to the Channel definition and each of the Protocol Processors.
[Protocol]
. . .
[Protocol]
. . .
[Protocol]
. . .
Protocol Section
Each Protocol Section defines what the incoming data stream looks like, how to break the data stream into packets, and how to parse out the fields in each of the packets. Multiple Protocol Sections can be defined for passing data from one Protocol Section to another.
Each Protocol Section has the following syntax that specifies the packetizing and parsing into fields.
[Protocol]
name = ProtocolName
[Packet]
packet processing settings
[Fields]
packet field processing settings
packet field processing settings
packet field processing settings
. . .
The ProtocolName is a label that uniquely identifies this protocol processor. This name is used in the Field definitions to define which Protocol to route a field of data (for use by multilayer protocols).
The highest level Protocol is the first protocol in the file. This is the Protocol Processor that is sent the incoming data stream from the bus as defined in the Channel Settings Dialog Box for that waveform.
Bus Events
Each bus type also can have certain bus events that may be significant in the decoding of a protocol. One such event is an I2C Start Bit. While the Start bit is not an actual bit in the data stream, it does signify to the I2C slave that a certain transaction is taking place. These bus events are inserted into the data stream and can be used (or ignored) by the protocol processors. The list of Bus Events supported is in the following table.
Bus Type : Event
Async
1 – Parity Error
I2C
1 - Start Bit
2 - Stop Bit
4 - ACK
8 – NACK
SPI
1 - SS Active
2 - SS Inactive
Note: You MUST have SS On in the channels settings for these events to occur
Data Channels and Multiple Data Signals
Some buses can also have more than one data signal used in the protocol. One example of this is the SPI bus, where for each byte sent on the MOSI line there is one byte received on the MISO line. In the protocol definition you can specify which of the signals to expect the next field of data to be sent on. In the SPI example, you may get a Command and Length field on one signal, followed by the read data back on the other signal. The decoder would take that into account and show the command, Length and Data as a single transaction.
Multiple signals are differentiated in the PacketPresenter using the X and Y channel specifiers. These channels are specified by selecting the signals to use for that bus in the Channel Settings dialog box. The following table shows which signals are the X and Y signals.
Packet Section
The Packet section defines how a packet is bounded and what, if any, preprocessing needs to be done on the packet before the fields can be processed.
[Packet]
[Start]
. . . // How does a packet start?
[End]
. . . // How does a packet end?
[Decode]
. . . // What decoding needs to be
// done to get real data?
Start and End Sections
The Start and End sections define how a packet is bounded. The available packet bounding Types are defined below:
For [START]
- Next: The next byte or bit is assumed the start of a packet
- Signal: An external signal indicates the start of a packet
- Value: A specific value in the data indicates the start of a packet
- Event: A bus specific bus Event or Events indicates the start of a packet
For [END]
- Next: The next byte or bit is assumed the end of a packet
- Signal: An external signal indicates the end of a packet
- Value: A specific value in the data indicates the end of a packet
- Length: A specific or calculated length determines the end of a packet
- Event: A bus specific bus Event or Events indicates the end of a packet
- Timeout: A packet ends after a set timeout without data or events
type = Next
The start or end of a packet is the next byte or bit to arrive.
[Packet]
[Start] or [End]
type = Next // Start/End of a packet is the next byte/bit to arrive
You can use the EXCLUDE keyword in the [END] section to leave the end data on the data stream for the next packet. This is useful for when there is no indication of the end of a packet except for the arrival of the next packet.
type = Signal
The start or end of a packet can be indicated by a separate signal (such as a chip select or a frame signal) using the signal setting.
[Packet]
[Start] or [End]
type = signal // Start/End of a packet is based on a signal
signal = signalvalue // Signal number 0 - 15
level = 1 // level the signal needs to be
type = Value
The start or end of a packet can be indicated by a certain data value contained in the data using the value setting. Multiple values can be used, where any one match starts or ends a packet. All bits in the Value are included in the resulting packet at the start of the packet. You must also specify the number of bits that the value covers (defaults to 8 bits if not specified) using the bits keyword. You can specify a mask value to apply to the start data and values. When the mask value has a bit that is a 1, that bit in the value and data are compared. All values are assumed MSB first.
[Packet]
[Start] or [End]
type = value // Start/End of a packet is based on a data value
mask = bitmask // Bitmask to apply to the data stream
value = value1 // value that the data needs to be to start/End
value = value2 // value that the data needs to be to start/End
value = value3 // value that the data needs to be to start/End
bits = 8 // how many bits in the start/End word
You can use the EXCLUDE keyword in the [END] section to leave the end data on the data stream for the next packet. This is useful for when there is no indication of the end of a packet except for the arrival of the next packet.
type = Length
Only valid in the [END] section, the end of a packet can be indicated by a certain length of data. You use the BitLength or the ByteLength keywords to specify how long the packet is. The length can either be a fixed length expressed as a constant, or variable length based on the contents of a packet in the data stream.
type = length // End of a packet is based on a length
Bytelength = length // How many bytes per packet
or
Bitlength = length // How many bits per packet
To use the contents of one of the fields as the packet length, you use the name of the field defined in the Fields section. You can also do simple arithmetic on the field value to compute the final packet size.
type = length // End of a packet is based on a length
Bytelength = fieldname * 2 + 2
// field holding packet size
// * (or /) a constant (optional)
// + (or -) a constant (optional)
If present, the * or / must come before the + or – offset and is executed first.
For example, if fieldname Field has the contents of 16, then the following is true:
fieldname * 2 + 2 = (16*2)+2 = 34
fieldname + 2 = 16+2 = 18
fieldname / 2 - 2 = (16/2)-2 = 6
fieldname / 2 = 16/2= 8
fieldname + 2 * 2 = invalid (* must come before offset)
fieldname - 2 / 2 = invalid (/ must come before offset)
The length of the packet includes ALL of the data from each of the data channels for that bus. If the bus contains only one data channel (such as I2C), the length counts all data on that one bus. If the bus has two data channels, the length refers to all data on both channels combined.
type = Event
The start or end of a packet can be indicated by the reception of any of the bus specific Events. For example in I2C you get a Bus Event for each Start Bit and a Bus Event for each Stop Bit. In USB you get a Bus Event for each Sync word and a Bus Event for each EOP.
The event value is a bitmask that includes all events that you want to use. If any of the events occur, a packet will be started or ended.
type = Event // Start/End of a packet is signaled by event
event = 1 // Use Event 1. Available events depend on bus type
or
event = 3 // Use either Event 1 or Event 2
type = Timeout
The end of a packet is determined by a timeout since the last valid data or event on the bus. The timeout is defined in units of microseconds.
[Packet]
[Start]
type = timeout // End is after timeout
timeout = 45 // microseconds since last data/event received
CHANNELX, CHANNELY or CHANNELXorY
CHANNELX, CHANNELY or CHANNELXorY specifies what channel is used when an event or data is defined for starting or ending a packet. Channel X and Channel Y are different based on what the physical bus is and can be found in Table 1. Channel X and Channel Y Definitions Per Bus Type. If it does not matter which channel the data or event occurs on (it could be either), use the CHANNELXorY keyword.
[Packet]
[Start]
type = value ; Start of a packet is based on
; a data value
value = 41h ; value of data that starts the
; packet
bits = 8
channelX ; data/event must be received
; on channel X
or
channelY ; data/event must be received
; on channel Y
or
channelXorY ; data/event must be received
; on either channel X or YDecode Section
Each packet can have encoding on the data that needs to be removed in order to see the real data. This section defines what decoding should be done to the packet. The entire packet from start to end is sent through the decoders. If only select parts of the packet needs to be decoded, you must create your own Add-In decoder using the ADDIN keyword.
Available decoding types are:
Keyword - Definition
NRZI - A bit change on the input means a 1 bit on the output, no change a 0
MANCHESTER - Remove Manchester encoding from data
INVERT - Invert all bits
ZBI5 - Zero-Bit Insertion removal (removes the 0 added after 5 1s)
ZBI6 - Zero-Bit Insertion removal (removes the 0 added after 6 1s)
substring - Substitute bytes in the stream (no spaces allowed)
Multiple decoders can be used and are processed in the order listed.
Substitutions
Substitutions allow a sequence of bytes (up to 3) to be replaced with a different set (same size or less) of bytes. They can only be used on bytestreams, not bitstreams. Substrings define the bytes input and the bytes output. The Substrings must not contain any spaces. Examples of this are below:
[1]=[2] // Replaces all 1s with 2s
[1][2]=[3] //; Replaces all 1 immediately followed by 2 with 3
[1][2]=[3][4] // Replaces all 1 immediately followed by 2 with 3 immediately followed by 4
[1][2][3]=[4] // Replaces all 1, 2, 3 with 4
[1]=[2][3][4] // INVALID, the number of output bytes must be less than or equal to the input
As an example, the HDLC protocol uses the byte value 7Eh as the start and end flag of the packets and replaces all 7Eh in the data with the bytes 7Dh followed by 5Eh. It also replaces all 7Dh in the data with the bytes 7Dh followed by 5Dh. To remove this coding you would use the lines:
[7Dh][5Eh]=[7Eh]
[7Dh][5Dh]=[7Dh]
Fields Section
Once the packet is delineated and decoded by the previous sections, it is ready to be displayed by the PacketPresenter. Since each packet is made up of fields, the Fields section defines how the packet is broken up into its fields and what to do with the field data.
Field Lines Processing
During processing, the Fields Section is processed one Field Line at a time in the order that they are listed in the FIELDS section. Each Field Line is parsed against the incoming data packets.
Once a single Field Line is successfully processed and output, the PacketPresenter starts over at the top of the Filed Lines list for the next packet. This ensures that there is only one output packet for each input packet for a given protocol.
There are 2 types of Field Lines. A Field Line can be conditional or unconditional. Unconditional Field Lines are processed for any packet. Conditional Field Lines are only processed if certain fields match a specific value.
Any Unconditional Field Line (no conditionals) generates an output line on the PacketPresenter screen. Any Conditional Field Line that evaluates to True generates an output line on the PacketPresenter screen. Any Conditional Field Line that evaluates to False is skipped and produces no output line on the PacketPresenter screen.
The Field Lines should be listed with the conditional field lines first followed by an unconditional field line to catch all packets that are not explicitly defined in the conditional field lines.
Unconditional Field Lines
Unconditional Field lines are parsed and decoded data is output for every packet that is input. The Fields specify how to interpret the data and how to output the data.
Conditional Field Lines
Conditional Field Lines provide a means for defining packets whose contents vary based upon the presence of a value in another field, either in this existing packet, or in a previous packet. An example of this is a packet that contains a Command Byte that determines the format of the rest of the packet. A Conditional Field Line contains at least one field in the packet that includes the =Value token in the input modifiers section. You can also use a field from a previous packet by specifying a bit length of zero, which will then use the most recent value of that field with that identical name in the previous packets. This is to handle protocols that are stateful based on the previous packets.
If the data contained in the conditional fields of a packet matches the =Value specified for the field, the packet is parsed and the data is output. If the condition field =Value does not match the incoming data, then the processor moves on to the next Field Line until it reaches the end of the Fields section.
Field Line Format
Each Field Line in the Fields Section has the keyword FIELDS followed by a series of individual Fields. Individual fields in a packet are separated by commas. A Field line in the Fields Section defines an entire packet from start to end and has the form:
Fields Field1,Field2,. . . ,FieldN
You can also insert a string to be printed out at that location in the packet by using the string ($) operator before the string to be printed. Below is an example of a field line with one string added between the fields.
Fields Field1,$String,. . . ,FieldN
Each field will be output with a Label and a Value. For String fields, just the String is output.
Field Format
Each field in the Field Line is defined using the following syntax and contains no spaces:
FieldName.InputModifiers (= value).OutputModifiers
FieldName is the name of the field. No spaces, commas, semicolons, brackets, dollar signs, periods, or quotes are allowed in the fieldname.
Input and output modifiers change the way incoming data and output data are formatted.
InputModifiers are a string of characters that represent how many bits are in the field and how the input data is to be handled. First is the number of bits in the field, or N if the field is a variable length. You can also specify a bit length of zero (0) to indicate that you want to use the value of that field from the most recent packet with that field name.
Next is any of the following:
- M: native bit order from that which came off of the bus (default)
- L: inverted bit order from that which came off of the bus
- B: invert the Byte order of this multibyte field
- X or Y: which channel the data is on (for multiline busses)
- =Value: Indicates that this field MUST be this value for the entire line to be processed (Conditional)
If the bit length at the beginning of the Input Modifier is non-zero, it compares the contents of THIS packet to the specified value. If the bitlength at the beginning of the Input Modifier is zero, it compares the specified value to the contents of this field (matched by fieldname) in the MOST RECENT packet.
Each modifier is a single character and multiple format modifiers can be combined.
There can only be one Variable length field (using the N input modifier) for each channel (x or y) for any given packet.
Example input modifiers are as follows:
8 // 8 bits
8L // 8 bits lsb first
8X // 8 bits from channel X
8Y // 8 bits from the Y channel
8=47h // 8 bits that must equal 47 hex. If they do not, then this line is ignored
0=47h // the most recent packet with a field called Fieldname must equal 47 hex. If not, this line is ignored.
N // all bits of the packet (on channel X) not used by other fields
NY // all bits on channel Y not used by other fields
OutputModifiers are a string of characters that represent how to output the contents of this data.
Output Modifiers are as follows:
- I Ignore - no output (entire field is ignored for output)
- D Decimal output (unsigned)
- S Decimal output (signed) - Sign Extend Bit is the MSBit of the field
- SValue Decimal output (signed) - Sign Extend Bit is the Value bit of the field
- H Hexadecimal output
- B Binary output
- A Ascii output
- TF True (nonzero) or False (zero)
- TFT True (nonzero) or False (zero), but only show if True
- TFF True (nonzero) or False (zero), but only show if False
- L Look up the text string to print out in a matching Lookup line
- *Value or /Value: a value to multiply/Divide the output value by
- +Value or -Value: a value to offset the output value by
- $string: string to print after the data (or in place of the data if the i flag is used). String must be the last item in a field. No commas, quotes, semicolons or parenthesis allowed in the string.
Bus Events in the middle of a packet
Sometimes a specific bus event plays a role in the packet format. To specify that a specific bus event needs to occur at a specific time in the field sequence, place the single Bus Event value inside brackets in the Field Line. Multiple events in a single value are not allowed, however consecutive events are allowed. To indicate the absence of a specific bus event in the protocol, use the ! (Not) operator.
For example, if the bus is I2C, use the following to require that a Start Bit is present between field1 and field2:
Fields Field1,[1],Field2
If there is a start bit between the 2 fields, then that Field Line will be processed.
And use the following to require that a Start Bit is NOT present between field1 and field2:
Fields Field1,[!1],Field2
If there is a start bit between the 2 fields, then that Field Line will not be processed.
Lookup Tables
Often fields contain values that mean something unrelated to the actual number of the data. Lookup Tables provide a way to output a string of text instead of a data value for a field. For each field wanting to use a lookup table, use the “L” output modifier in the field format and then define the table in the FIELDS section using the LOOKUP keyword.
The format of the Lookup table is as follows:
LOOKUP Fieldname
[value1]=$string1
[value2]=$string2
. . .
Fieldname is the name of the field associated with this lookup table. valuen refers to the actual data value of the field. stringn is the text string that is output instead of the valuen.
If a lookup entry is not present for the data value (not found in the Lookup Table or the Lookup Table does not exist), then the data value is output.
For example, the following table will assign the text strings for various values of the data for the CommandByte field. When the field CommandByte,8,L is processed, the strings are output instead of the value
Lookup CommandByte [0]=$Read [1]=$Write [2]=$Seek [3]=$Loc [4]=$Size
The Lookup Tables are only associated to the specific Protocol they are contained in. Therefore you can have a CommandByte lookup table in ProtocolA that is different from a CommandByte lookup table in ProtocolB. Within a single Protocol, you need to make sure that the Fieldnames are unique for all Lookup Tables so that the PacketPresenter can determine which table to use.
Examples of Field Lines and Fields
Just Plain Data
Fields contain data that may or may not be of interest to the user. Many times the data is information that just needs to be output to the viewer. Being binary data, each field may need to be translated numerically to mean something. To output a field of data, you can specify the radix (if it should be shown in Hex, Decimal, binary) as well as a gain and offset to scale the data. Finally you can add a string to the field to complete the information. All scaling is performed first using floating point and then the output formatting is applied.
Below is an example of a field to just output the data.
Fields Volts.16m.d*1.5-37.256$mV
This Field Line contains one field named “Volts”, which is 16 bits long in msbit first order. The output is to be displayed in decimal format, multiplied by 1.5, offset by - 37.256 and finally appended with “mV” before output to the PacketPresenter screen.
For an input packet as follows:
0000001100001100. . .
The output would be:
Volts = 1132.744mV
which is the input 16 bits in msbfirst order (0x30C) times the gain of 1.5 plus the offset of -37.256 output in decimal format plus the “mV” string.
Conditional Packet Format
Using the Conditional input modifier, many different field arrangements can be defined for the same packet. Common uses are for parameter fields that exist for different types of commands. If packets contain commands that determine what the remaining fields are, this syntax defines what those remaining fields are.
Below is an example of various packet formats based on a single command field.
Fields Command.4m=0.h,Address.8m.h
Fields Command.4m=2.h,Address.8m.h,Data.8m.h
Fields Command.4m=4.h,Param1.8m.h,Param2.8m.h,Param3.8m.h
For an input packet as follows:
0010 00011101 00001000. . .
Followed by a packet:
0100 00011101 00001000 11111110. . .
The output would be:
Command = 2, Address = 1D, Data = 08
Command = 4, Param1 = 1D, Param2 = 08, Param3 = FE
which are the fields associated with the Command=2 and Command=4 Field Lines.
String Lookup
Fields that can be better expressed as text strings can be outputted as such using a Lookup table.
Below is an example of a field that uses a lookup table.
[Fields] Fields StartByte.8.H, CommandByte.8.L, EndByte.8.H Lookup CommandByte [0]=$Read [1]=$Write [2]=$Seek [3]=$Loc [4]=$Size
For an input packet as follows:
00100001 00000001 00001000. . .
The output would be:
StartByte = 21, Command = Write, EndByte = 08
which is the text associated with the Command Field 4 bits in msbfirst order (0010b = 2).
Conditional Route of data to another Protocol
Many embedded protocols support multiple layers of protocol, where each protocol layer handles a different set of services or functions. In these multilayer protocols, a field of data from one protocol layer may be the input data to another layer of protocol. Routing this field of data to a new Protocol is as easy as naming the Field the same name as the Protocol. If the Field name matches any protocol, the entire data for that field is passed to that Protocol for processing.
Below is an example that shows a field being sent to a new layer (Layer2) of protocol when the command field is a 1.
[Protocol]
name = Layer1
[Packet]
[Decode]
[Fields]
Fields Command.4=0.h,Address.8.h
Fields Command.4=1.h,Layer2.48.h
[Protocol]
name = Layer2
[Packet]
[Decode]
[Fields]
Fields L2Command.4=0.h,RSSI.8.d
Fields L2Command.4=1.h,QoS.16.d
Fields L2Command.4=2.h,Layer3.44.h
PacketPresenter Definition File Debugging
Creating your PacketPresenter Definition File can be made simpler using the Debug mode. To turn on Debug mode, use the DebugOn keyword in ALL [DEBUG] sections of the Definition File.
[Protocol]
name = I2CEEPROM
[DEBUG]
DebugOn ; Turns On Debug Mode.
; Comment it out to turn it off.
[Packet]
When debug mode is on, each packet is output twice in its raw form, showing the data values as well as the events from the bus. The first debug line is the initial bus data. The second line is the bus data after any decoding is completed. Following the debug lines are the PacketPresenter output packets from this same data.
Below is a screen shot that shows the PacketPresenter that has Debug turned on.
PacketPresenter Specifications
The PacketPresenter system has the following limits regarding file size, packets, fields, lookup tables etc.
● 100K bytes per PacketPresenter Definition File
● 64K Data Records per Packet (min 64K bits, max 64K bytes)
● 7 Protocols
● 1024 Field Lines per Protocol
● 128 Fields per Field Line
● 64 Lookup Tables per Protocol
● 256 Lookup entries per Lookup Table
● 256 Decoder Substitutions per Protocol
● 3 Bytes per Substitution input or output
● 4 PacketPresenter Windows
● 2.1B bytes per PacketPresenter Output File
Packet Presenter Definition Library
To contribute your Packet Presenter Definitions, please send them to us at support@activefirmwaretools.com
-
[Protocol]
name = UART_ASCII
bytewise
[Packet]
[Start]
type = next
[End]
type = value
value = 13
[Decode]
[Fields]
Fields Tx.Nx.a, Rx.Ny.a
-
[Protocol]
name = UART_ASCII
bytewise
[Packet]
[Start]
type = next
[End]
type = value
value = 10
[Decode]
[Fields]
Fields Tx.Nx.a, Rx.Ny.a
-
[Protocol]
name = UART_ASCII
bytewise
[Packet]
[Start]
type = next
[End]
type = value
value = 0
[Decode]
[Fields]
Fields Tx.Nx.a, Rx.Ny.a
-
[Protocol]
name = UART_BINARY
bytewise
[Packet]
[Start]
type = next
[End]
type = timeout
value = 170 // timeout in microseconds
[Decode]
[Fields]
Fields Tx.Nx.h, Rx.Ny.h
-
[Protocol]
name = I2C_Packets // This name is used for the waveline name on the capture
bytewise
[Packet]
[Start]
type = event
event = 1 // Start bit
[End]
type = event
event = 2 // Stop Bit
[Decode]
[Fields]
Fields dev.7m.h, RW.1.L, add.8m.h, [1], dev.7m.h, RW.1.L, data.Nm.h // Read with 8-bit address
Fields dev.7m.h, RW.1.L, add.16m.h, [1], dev.7m.h, RW.1.L, data.Nm.h // Read with 16-bit address
Fields dev.7m.h, RW.1=1.L, data.Nm.h // Read Transaction
Fields dev.7m.h, RW.1.L, add.8m.h, data.Nm.h // Write Transaction
Lookup RW
[0]=$Write
[1]=$Read
-
[Protocol]
name = SPI_Packets
bytewise
[Packet]
[Start]
type = event
event = 1 // SS Active
[End]
type = event
event = 2 // SS Inactive
[Decode]
[Fields]
Fields MOSIData.Nx.h, MISOData.Ny.h
-
[Protocol]
name = CypressRFIC
bytewise
[Packet]
[Start]
type = event
event = 1 // SS goes active
[End]
type = event
event = 2 // SS goes inactive
[Decode]
[Fields]
// RX_IRQ_STATUS_ADR Read and Write Command
Fields Dir.1y=0.L, Inc.1y.tf, Address.6y=07h.L, Dummy.8x.i, RXOW.1x.h,
SOPDET.1x.h, RXB16.1x.h, RXB8.1x.h, RXB1.1x.h, RXBERR.1x.h, RXC.1x.h,
RXE.1x.h
Fields Dir.1y=1.L, Inc.1y.tf, Address.6y=07h.L, RXOW.1y.h, SOPDET.1y.h,
RXB16.1y.h, RXB8.1y.h, RXB1.1y.h, RXBERR.1y.h, RXC.1y.h, RXE.1y.h
// TX_IRQ_STATUS_ADR Read and Write Command
Fields Dir.1y=0.L, Inc.1y.tf, Address.6y=04h.L, Dummy.8x.i, OS.1x.h, LV.1x.h,
TXB15.1x.h, TXB8.1x.h, TXB1.1x.h, TXBERR.1x.h, TXC.1x.h, TXE.1x.h
Fields Dir.1y=1.L, Inc.1y.tf, Address.6y=04h.L, OS.1y.h, LV.1y.h, TXB15.1y.h,
TXB8.1y.h, TXB1.1y.h, TXBERR.1y.h, TXC.1y.h, TXE.1y.h
// RX_BUFFER_ADR Read and Write Command
Fields Dir.1y=0.L, Inc.1y.tf, Address.6y=21h.L, Dummy.8x.i,
RXData.Nx.h
Fields Dir.1y=1.L, Inc.1y.tf, Address.6y=21h.L, RXData.Ny.h
// TX_BUFFER_ADR Read and Write Command
Fields Dir.1y=0.L, Inc.1y.tf, Address.6y=20h.L, Dummy.8x.i,
TxData.Nx.h
Fields Dir.1y=1.L, Inc.1y.tf, Address.6y=20h.L, TxData.Ny.h
Fields Dir.1y=0.L, Inc.1y.tf, Address.6y.L, Dummy.8x.i,
ReadData.Nx.h
Fields Dir.1y=1.L, Inc.1y.tf, Address.6y.L, WriteData.Nmy.h
Lookup Dir
[0]=$Read
[1]=$Write
Lookup Address
[00h]=$CHANNEL_ADR
[01h]=$TX_LENGTH_ADR
[02h]=$TX_CTRL_ADR
[03h]=$TX_CFG_ADR
[04h]=$TX_IRQ_STATUS_ADR
[05h]=$RX_CTRL_ADR
[06h]=$RX_CFG_ADR
[07h]=$RX_IRQ_STATUS_ADR
[08h]=$RX_STATUS_ADR
[09h]=$RX_COUNT_ADR
[0ah]=$RX_LENGTH_ADR
[0bh]=$PWR_CTRL_ADR
[0ch]=$XTAL_CTRL_ADR
[0dh]=$IO_CFG_ADR
[0eh]=$GPIO_CTRL_ADR
[0fh]=$XACT_CFG_ADR
[10h]=$FRAMING_CFG_ADR
[11h]=$DATA32_THOLD_ADR
[12h]=$DATA64_THOLD_ADR
[13h]=$RSSI_ADR
[14h]=$EOP_CTRL_ADR
[15h]=$CRC_SEED_LSB_ADR
[16h]=$CRC_SEED_MSB_ADR
[17h]=$TX_CRC_LSB_ADR
[18h]=$TX_CRC_MSB_ADR
[19h]=$RX_CRC_LSB_ADR
[1ah]=$RX_CRC_MSB_ADR
[1bh]=$TX_OFFSET_LSB_ADR
[1ch]=$TX_OFFSET_MSB_ADR
[1dh]=$MODE_OVERRIDE_ADR
[1eh]=$RX_OVERRIDE_ADR
[1fh]=$TX_OVERRIDE_ADR
[26h]=$XTAL_CFG_ADR
[27h]=$CLK_OVERRIDE_ADR
[28h]=$CLK_EN_ADR
[29h]=$RX_ABORT_ADR
[32h]=$AUTO_CAL_TIME_ADR
[35h]=$AUTO_CAL_OFFSET_ADR
[39h]=$ANALOG_CTRL_ADR
[20h]=$TX_BUFFER_ADR
[21h]=$RX_BUFFER_ADR
[22h]=$SOP_CODE_ADR
[23h]=$DATA_CODE_ADR
[24h]=$PREAMBLE_ADR
[25h]=$MFG_ID_ADR
[Protocol]
name = RXData
bytewise
[Packet]
[Start]
type = next
[End]
type = event
event = 127 // All Data passed in
[Decode]
[Fields]
Fields ReceiveData.N.h
-
// Protocol Definition File for the TMP117 Temperature Sensor
[Protocol]
name = TMP117_I2C
bytewise
[Packet]
[Start]
type = event
event = 1 // Start bit
[End]
type = event
event = 2 // Stop Bit
[Decode]
[Fields]
// Write then Read Registers
Fields dev.7m=48h.h, RW.1=0.L, add.8m=0h.L, [1], dev.7m=48h.h, RW.1=1.L, temperature.Nm.d*7.8125$mC
Fields dev.7m=48h.h, RW.1=0.L, add.8m=1h.L, [1], dev.7m=48h.h, RW.1=1.L, configuration.Nm.h
Fields dev.7m=48h.h, RW.1=0.L, add.8m=2h.L, [1], dev.7m=48h.h, RW.1=1.L, Temperature_high_limit.Nm.h
Fields dev.7m=48h.h, RW.1=0.L, add.8m=3h.L, [1], dev.7m=48h.h, RW.1=1.L, Temperature_low_limit.Nm.h
Fields dev.7m=48h.h, RW.1=0.L, add.8m=4h.L, [1], dev.7m=48h.h, RW.1=1.L, EEPROM_unlock.Nm.h
Fields dev.7m=48h.h, RW.1=0.L, add.8m=5h.L, [1], dev.7m=48h.h, RW.1=1.L, EEPROM1.Nm.h
Fields dev.7m=48h.h, RW.1=0.L, add.8m=6h.L, [1], dev.7m=48h.h, RW.1=1.L, EEPROM2.Nm.h
Fields dev.7m=48h.h, RW.1=0.L, add.8m=7h.L, [1], dev.7m=48h.h, RW.1=1.L, Temperature_offset.Nm.h
Fields dev.7m=48h.h, RW.1=0.L, add.8m=8h.L, [1], dev.7m=48h.h, RW.1=1.L, EEPROM3.Nm.h
Fields dev.7m=48h.h, RW.1=0.L, add.8m=Fh.L, [1], dev.7m=48h.h, RW.1=1.L, Device_ID.Nm.h
// Single Read Registers
Fields dev.7m=48h.h, RW.1=1.L, add.8m=0.i, temperature.Nm.d*7.8125$mC
Fields dev.7m=48h.h, RW.1=1.L, add.8m=1.i, configuration.Nm.h
Fields dev.7m=48h.h, RW.1=1.L, add.8m=2.i, Temperature_high_limit.Nm.h
Fields dev.7m=48h.h, RW.1=1.L, add.8m=3.i, Temperature_low_limit.Nm.h
Fields dev.7m=48h.h, RW.1=1.L, add.8m=4.i, EEPROM_unlock.Nm.h
Fields dev.7m=48h.h, RW.1=1.L, add.8m=5.i, EEPROM1.Nm.h
Fields dev.7m=48h.h, RW.1=1.L, add.8m=6.i, EEPROM2.Nm.h
Fields dev.7m=48h.h, RW.1=1.L, add.8m=7.i, Temperature_offset.Nm.h
Fields dev.7m=48h.h, RW.1=1.L, add.8m=8.i, EEPROM3.Nm.h
Fields dev.7m=48h.h, RW.1=1.L, add.8m=Fh.i, Device_ID.Nm.h
Fields dev.7m=48h.h, RW.1=1.L, data.Nm.h
// Write Registers
Fields dev.7m=48h.h, RW.1=0.L, add.8m.L, data.Nm.h
Lookup RW
[0]=$Write
[1]=$Read
Lookup add
[0h]=$Temperature_Result
[1h]=$Configuration
[2h]=$Temperature_high_limit
[3h]=$Temperature_low_limit
[4h]=$EEPROM_unlock
[5h]=$EEPROM1
[6h]=$EEPROM2
[7h]=$Temperature_offset
[8h]=$EEPROM3
[Fh]=$Device_ID
-
// Protocol Definition File for the BMA400 Accelerometer
[Protocol]
name = BMA400_I2C
bytewise
[Packet]
[Start]
type = event
event = 1 // Start bit
[End]
type = event
event = 2 // Stop Bit
[Decode]
[Fields]
// Packet Decodes for the BMA400
//Fields BMA400_DEV.7m=14h.h, RW.1=0.L, BMA400_REG.8m.L, [1], BMA400_DEV.7m=14h.L, RW.1=1.L, DATA.Nm.h // Write then Read Registers
Fields BMA400_DEV.7m=14h.h, READ.1=1.h, BMA400_REG.0=04h.i, X_AXIS.16B.S11, Y_AXIS.16B.S11, Z_AXIS.16B.S11
Fields BMA400_DEV.7m=14h.h, READ.1=1.h, BMA400_REG.0.L, DATA.Nm.h // Single Read Registers
Fields BMA400_DEV.7m=14h.h, WRITE.1=0.h, BMA400_REG.8m.L, DATA.Nm.h // Write Registers
// For I2C Devices that are not included above
Fields DEV.7m.h, RW.1=0.L, REG.8m.h, [1], DEV.7m.h, RW.1=1.l, DATA.Nm.h // Write then Read Registers
Fields DEV.7m.h, RW.1=1.L, REG.0.h, DATA.Nm.h // Single Read Registers
Fields DEV.7m.h, RW.1=0.L, REG.8m.h, DATA.Nm.h // Write Registers
Lookup RW
[0h]=$WRITE
[1h]=$READ
Lookup BMA400_REG
[00h]=$CHIPID
[01h]=$RESERVED
[02h]=$ERR_REG
[03h]=$STATUS
[04h]=$ACC_X_LSB
[05h]=$ACC_X_MSB
[06h]=$ACC_Y_LSB
[07h]=$ACC_Y_MSB
[08h]=$ACC_Z_LSB
[09h]=$ACC_Z_MSB
[0Ah]=$SENSOR_TIME_0
[0Bh]=$SENSOR_TIME_1
[0Ch]=$SENSOR_TIME_2
[0Dh]=$EVENT
[0Eh]=$INT_STAT0
[0Fh]=$INT_STAT1
[10h]=$INT_STAT2
[11h]=$TEMP_DATA
[12h]=$FIFO_LENGTH0
[13h]=$FIFO_LENGTH1
[14h]=$FIFO_DATA
[15h]=$STEP_CNT0
[16h]=$STEP_CNT1
[17h]=$STEP_CNT2
[18h]=$STEP_STAT
[19h]=$ACC_CONFIG0
[1Ah]=$ACC_CONFIG1
[1Bh]=$ACC_CONFIG2
[1Fh]=$INT_CONFIG0
[20h]=$INT_CONFIG1
[21h]=$INT1_MAP
[22h]=$INT2_MAP
[23h]=$INT12_MAP
[24h]=$INT12_IO_CTRL
[26h]=$FIFO_CONFIG0
[27h]=$FIFO_CONFIG1
[28h]=$FIFO_CONFIG2
[29h]=$FIFO_PWR_CONFIG
[2Ah]=$AUTOLOWPOW_0
[2Bh]=$AUTOLOWPOW_1
[2Ch]=$AUTOWAKEUP_0
[2Dh]=$AUTOWAKEUP_1
[2Fh]=$WKUP_INT_CONFIG_0
[30h]=$WKUP_INT_CONFIG_1
[31h]=$WKUP_INT_CONFIG_2
[32h]=$WKUP_INT_CONFIG_3
[33h]=$WKUP_INT_CONFIG_4
[35h]=$ORIENTCH_CONFIG0
[36h]=$ORIENTCH_CONFIG1
[38h]=$ORIENTCH_CONFIG3
[39h]=$ORIENTCH_CONFIG4
[3Ah]=$ORIENTCH_CONFIG5
[3Bh]=$ORIENTCH_CONFIG6
[3Ch]=$ORIENTCH_CONFIG7
[3Dh]=$ORIENTCH_CONFIG8
[3Eh]=$ORIENTCH_CONFIG9
[3Fh]=$GEN1INT_CONFIG0
[40h]=$GEN1INT_CONFIG1
[41h]=$GEN1INT_CONFIG2
[42h]=$GEN1INT_CONFIG3
[43h]=$GEN1INT_CONFIG31
[44h]=$GEN1INT_CONFIG4
[45h]=$GEN1INT_CONFIG5
[46h]=$GEN1INT_CONFIG6
[47h]=$GEN1INT_CONFIG7
[48h]=$GEN1INT_CONFIG8
[49h]=$GEN1INT_CONFIG9
[4Ah]=$GEN1INT_CONFIG0
[4Bh]=$GEN1INT_CONFIG1
[4Ch]=$GEN1INT_CONFIG2
[4Dh]=$GEN1INT_CONFIG3
[4Eh]=$GEN1INT_CONFIG31
[4Fh]=$GEN1INT_CONFIG4
[50h]=$GEN1INT_CONFIG5
[51h]=$GEN1INT_CONFIG6
[52h]=$GEN1INT_CONFIG7
[53h]=$GEN1INT_CONFIG8
[54H]=$GEN1INT_CONFIG9
[55h]=$ACTH_CONFIG0
[56h]=$ACTH_CONFIG1
[57h]=$TAP_CONFIG0
[58h]=$TAP_CONFIG1
[7Ch]=$IF_CONFIG
[7Dh]=$SELF_TEST
[7Eh]=$CMD
-
// Default Protocol Definition File
// This file defines the transfers to/from a custom device
[Protocol]
name = MDIO_Packets // This name is used for the waveline name on the capture
bytewise
[Packet]
[Start]
type = event
event = 1 // Start bit
[End]
type = event
event = 2 // Stop Bit
[Decode]
[Fields]
Fields ST.2=1.L, OP22.2.L, PHYADR.5.h, REGADR.5.h, TA.2.i, DATA.16.h
Fields ST.2=0.L, OP45.2.L, PHYADR.5.h, DEVTYPE.5.h, TA.2.i, ADDRDATA.16.h
LOOKUP ST
[0]=$clause22
[1]=$clause45
LOOKUP OP22
[1]=$WRITE
[2]=$READ
LOOKUP OP45
[0]=$ADDRESS
[1]=$WRITE
[2]=$READ_ADDR
[3]=$READ
LOOKUP DEVTYPE
[0]=$RESERVED
[1]=$PMDPMA
[2]=$WIS
[3]=$PCS
[4]=$PHYXS
[5]=$DTEXS
-
// Default Protocol Definition File
// This file defines the transfers to/from a custom device
[Protocol]
name = UART_Packets
bytewise
9bit
[Packet]
[Start]
type = next
channelxory
[End]
type = value
value = 0Dh // Assumes UART data ends with a CR
channelxory
[Decode]
[Fields]
Fields A.1x=1.i, Address.8x.h, TxData.Nx.h
Fields A.1y=1.i, Address.8y.h, RxData.Ny.h
-
// Bi Phase Protocol Definition File
// This file defines the transfers to/from a custom device
// over an biphase bus
[Protocol]
name = DS101_PACKET
bytewise
[Packet]
[Start]
type = event // Start Packet event
event = 1
[End]
type = event
event = 2 // Stop Packet event
[Decode]
[Fields]
Fields Address.8.h,$SNRM_Frame, Command.8=93h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$SNRM_Frame, Command.8=83h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$SNRM_Frame, Command.8=93h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$UA_Frame, Command.8=63h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$UA_Frame, Command.8=73h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$DISC_Frame, Command.8=43h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$DISC_Frame, Command.8=53h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RNR_Frame, Command.8=23h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RNR_Frame, Command.8=33h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=01h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=11h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=21h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=31h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=41h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=51h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=61h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=71h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=81h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=91h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=A1h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=B1h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=C1h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=D1h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=E1h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$RR_Frame, Command.8=F1h.i, Params.N.h, EOP.16.i
Fields Address.8.h,$I_Frame, Command.8.h, FDU_COMMAND.16.L, Length.16.d, Params.N.h, CRC.16.h, EOP.8.i
Fields Address.8.h,Command.8.L, Params.N.h
Fields DefaultData.N.h
LOOKUP Command
[93h]=$SNRM
[83h]=$SNRM
[73h]=$UA
[63h]=$UA
[53h]=$DISC
[43h]=$DISC
[33h]=$RNR
[23h]=$RNR
LOOKUP FDU_COMMAND
[0000h]=$End_of_Transmission.request
[0002h]=$Success_Acknowledgment_w/o_Data
[0001h]=$Failure_Acknowledgment_w/o_Data
[0003h]=$Failure_Acknowledge_with_Data
[0010h]=$Set_Address.request
[0030h]=$Set_Identifier.request
[0050h]=$Association_and_Exchange_Identifier.request
[0060h]=$Association_and_Exchange_Identifier.response
[01B0h]=$Key/Data.request_(Fill)
[03FFh]=$Command.request
[0070h]=$Field_Specifier.request
[0190h]=$File_Header.request_(Fill)
[0290h]=$File_Header.request_(Issue)
[0198h]=$End_of_File.request_(Fill)
[0298h]=$End_of_File.request_(Issue)
[02B0h]=$Key/Data.request_(Issue)
[01B8h]=$Program/File_Data.request_(Fill)
[02B8h]=$Program/File_Data.request_(Issue)
[01D0h]=$CIK_Split.request_(Fill)
[02D0h]=$CIK_Split.request_(Issue)
[01D8h]=$DTD_Split.request_(Fill)
[02D8h]=$DTD_Split.request_(Issue)
[01E0h]=$TrKEK.request_(Fill)
[02E0h]=$TrKEK.request_(Issue)
-
// Default Protocol Definition File
// This file defines the transfers to/from a custom device
[Protocol]
name = CHSI_Packets // This name is used for the waveline name on the capture
bytewise
[Packet]
[Start]
type = event
event = 1 // Start bit
[End]
type = event
event = 3 // Start or Stop Bit
exclude
[Decode]
[Fields]
Fields $GetCryptoStatus, routing.8.i, ID.8=65h.h, len.8.h, CRC.16B.h
Fields $GetCryptoStatusResponse, routing.8.i, ID.8=75h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $KeyRolloverRequest, routing.8.i, ID.8=40h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $ACK, routing.8.i, ID.8=FFh.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $UnavailableNAK, routing.8.i, ID.8=FAh.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $IllegalNAK, routing.8.i, ID.8=FBh.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $BusyNAK, routing.8.i, ID.8=FCh.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $MessageErrorNAK, routing.8.i, ID.8=FDh.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $CRCErrorNAK, routing.8.i, ID.8=FEh.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $SetTimeofDayRequest, routing.8.i, ID.8=41h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $SetTimeofDayResponse, routing.8.i, ID.8=51h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetTimeofDayRequest, routing.8.i, ID.8=60h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetTimeofDayResponse, routing.8.i, ID.8=70h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetMissionDataRequest, routing.8.i, ID.8=61h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetMissionDataResponse, routing.8.i, ID.8=71h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetKeyandFillStatusRequest, routing.8.i, ID.8=62h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetKeyandFillStatusResponse, routing.8.i, ID.8=72h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $SetCryptoOperatingModeRequest, routing.8.i, ID.8=42h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $ZeroizeRequest, routing.8.i, ID.8=43h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $RunIBIT, routing.8.i, ID.8=44h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetIBITResultsRequest, routing.8.i, ID.8=63h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetIBITResultsResponse, routing.8.i, ID.8=73h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetVersionRequest, routing.8.i, ID.8=64h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GetVersionResponse, routing.8.i, ID.8=74h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $SetCryptonetRequest, routing.8.i, ID.8=45h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $ResetCryproRequest, routing.8.i, ID.8=46h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $TransecUpdate, routing.8.i, ID.8=20h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $AvailabilityAlertAdvisory, routing.8.i, ID.8=80h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GenerateTRANSECRequest, routing.8.i, ID.8=21h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $GenerateTRANSECResponse, routing.8.i, ID.8=31h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $PGInterrogationEncryptRequest, routing.8.i, ID.8=00h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $PGInterrogationEncryptResponse, routing.8.i, ID.8=10h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $PGInterrogationDecryptRequest, routing.8.i, ID.8=04h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $PGInterrogationDecryptResponse, routing.8.i, ID.8=14h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $PGReportEncryptRequest, routing.8.i, ID.8=01h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $PGReportEncryptResponse, routing.8.i, ID.8=11h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $PGReportDecryptRequest, routing.8.i, ID.8=05h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $PGReportDecryptResponse, routing.8.i, ID.8=15h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $IDReplyEncryptRequest, routing.8.i, ID.8=08h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $IDReplyEncryptResponse, routing.8.i, ID.8=18h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $DataReplyEncryptRequest, routing.8.i, ID.8=09h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $DataReplyEncryptResponse, routing.8.i, ID.8=19h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $ReplyDecryptRequest, routing.8.i, ID.8=0Ah.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $ReplyDecryptResponse, routing.8.i, ID.8=1Ah.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $HDInterrogationEncryptRequest, routing.8.i, ID.8=02h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $HDInterrogationEncryptResponse, routing.8.i, ID.8=12h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $HDInterrogationDecryptRequest, routing.8.i, ID.8=06h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $HDInterrogationDecryptResponse, routing.8.i, ID.8=16h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $HDReportEncryptRequest, routing.8.i, ID.8=03h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $HDReportEncryptResponse, routing.8.i, ID.8=13h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $HDReportDecryptRequest, routing.8.i, ID.8=07h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields $HDReportDecryptResponse, routing.8.i, ID.8=17h.h, len.8.h, data.Nm.h, CRC.16B.h
Fields routing.8.i, ID.8.L, len.8.h, data.Nm.h, CRC.16B.h
Lookup ID
[65h]=$GetCryptoStatus
[75h]=$GetCryptoStatusResponse
[40h]=$KeyRolloverRequest
[FFh]=$ACK
[FAh]=$UnavailableNAK
[FBh]=$IllegalNAK
[FCh]=$BusyNAK
[FDh]=$MessageErrorNAK
[FEh]=$CRCErrorNAK
[41h]=$SetTimeofDayRequest
[51h]=$SetTimeofDayResponse
[60h]=$GetTimeofDayRequest
[70h]=$GetTimeofDayResponse
[61h]=$GetMissionDataRequest
[71h]=$GetMissionDataResponse
[62h]=$GetKeyandFillStatusRequest
[72h]=$GetKeyandFillStatusResponse
[42h]=$SetCryptoOperatingModeRequest
[43h]=$ZeroizeRequest
[44h]=$RunIBIT
[63h]=$GetIBITResultsRequest
[73h]=$GetIBITResultsResponse
[64h]=$GetVersionRequest
[74h]=$GetVersionResponse
[45h]=$SetCryptonetRequest
[46h]=$ResetCryproRequest
[20h]=$TransecUpdate
[80h]=$AvailabilityAlertAdvisory
[21h]=$GenerateTRANSECRequest
[31h]=$GenerateTRANSECResponse
[00h]=$PGInterrogationEncryptRequest
[10h]=$PGInterrogationEncryptResponse
[04h]=$PGInterrogationDecryptRequest
[14h]=$PGInterrogationDecryptResponse
[01h]=$PGReportEncryptRequest
[11h]=$PGReportEncryptResponse
[05h]=$PGReportDecryptRequest
[15h]=$PGReportDecryptResponse
[08h]=$IDReplyEncryptRequest
[18h]=$IDReplyEncryptResponse
[09h]=$DataReplyEncryptRequest
[19h]=$DataReplyEncryptResponse
[0Ah]=$ReplyDecryptRequest
[1Ah]=$ReplyDecryptResponse
[02h]=$HDInterrogationEncryptRequest
[12h]=$HDInterrogationEncryptResponse
[06h]=$HDInterrogationDecryptRequest
[16h]=$HDInterrogationDecryptResponse
[03h]=$HDReportEncryptRequest
[13h]=$HDReportEncryptResponse
[07h]=$HDReportDecryptRequest
[17h]=$HDReportDecryptResponse
-
// Default Protocol Definition File
// This file defines the transfers to/from a custom device
[Protocol]
name = 1_WIRE_P_PACKETS
bitwise
[Packet]
[Start]
type = event
event = 1 // Presence
[End]
type = event
event = 2 // Reset
[Decode]
[Fields]
// These fields are used by Maxim/Dallas Digital Thermometers
Fields ROMCommand.8=F0h.$Search Rom, Data.N.h
Fields ROMCommand.8=33h.$Read Rom, Family.8.h, SerialNumber.48.h, CRC.8.h
Fields ROMCommand.8=55h.$Match Rom, Family.8.h, SerialNumber.48.h, CRC.8.h
Fields ROMCommand.8=CCh.$Skip ROM, Function.8=44h.$ConvertTemp
Fields ROMCommand.8=CCh.$Skip ROM, Function.8=BEh.$Read Scratchpad, Temp.16.d, TH.8.h, TL.8l.h, Rsvd.16.i, Remain.8.h, CpC.8.h, CRC.8.h
// These fields are used by Dallas Serial Number iButtons
Fields ROMCommand.8=33h.$Read Rom, Family.8.h, SerialNumber.48.h, CRC.8.h
Fields ROMCommand.8=0Fh.$Read Rom, Family.8.h, SerialNumber.48.h, CRC.8.h
// These packets are used by 1-Wire EEPROMS
Fields ROMCommand.8=33h.$Read Rom, Family.8.h, SerialNumber.48.h, CRC.8.h
Fields ROMCommand.8.h, MemoryCommand.8=0Fh.$Write Scratchpad, Address.16.h, Data.N.h
Fields ROMCommand.8.h, MemoryCommand.8=AAh.$Read Scratchpad, Address.16.h, ES.8.h, Data.N.h
Fields ROMCommand.8.h, MemoryCommand.8=55h.$Copy Scratchpad, AuthCode.24.h
Fields ROMCommand.8.h, MemoryCommand.8=F0h.$Read Memory, Address.16.h, Data.N.h
// Catch All
Fields ROMCommand.8.h, Data.N.h