MCP SERIAL TRANSPORT PROTOCOL REFERENCE MANUAL Manual Part Number 99875163-Rev 5 APRIL 2007 REGISTERED TO ISO 9001:2000 1710 Apollo Court Seal Beach, CA 90740 Phone: (562) 546-6400 FAX: (562) 546-6301 Technical Support: (651) 415-6800 www.magtek.
Copyright© 2000-2007 MagTek®, Inc. Printed in the United States of America Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of MagTek, Inc. MagTek is a registered trademark of MagTek, Inc.
SOFTWARE LICENSE AGREEMENT IMPORTANT: YOU SHOULD CAREFULLY READ ALL THE TERMS, CONDITIONS AND RESTRICTIONS OF THIS LICENSE AGREEMENT BEFORE INSTALLING THE SOFTWARE PACKAGE. YOUR INSTALLATION OF THE SOFTWARE PACKAGE PRESUMES YOUR ACCEPTANCE OF THE TERMS, CONDITIONS, AND RESTRICTIONS CONTAINED IN THIS AGREEMENT. IF YOU DO NOT AGREE WITH THESE TERMS, CONDITIONS, AND RESTRICTIONS, PROMPTLY RETURN THE SOFTWARE PACKAGE AND ASSOCIATED DOCUMENTATION TO ABOVE ADDRESS ATTENTION: CUSTOMER SUPPORT.
ACKNOWLEDGMENT: LICENSEE ACKNOWLEDGES THAT HE HAS READ THIS AGREEMENT, UNDERSTANDS ALL OF ITS TERMS, CONDITIONS AND RESTRICTIONS AND AGREES TO BE BOUND BY THEM. LICENSEE ALSO AGREES THAT THIS AGREEMENT SUPERSEDES ANY AND ALL, VERBAL AND WRITTEN, COMMUNICATIONS BETWEEN LICENSOR AND LICENSEE OR THEIR ASSIGNS RELATING TO THE SUBJECT MATTER OF THIS AGREEMENT.
TABLE OF CONTENTS SECTION 1. OVERVIEW............................................................................................................................. 1 SECTION 2. TRANSPORT FRAME FORMAT ........................................................................................... 3 COMMON FRAME FORMAT DEFINITION.............................................................................................. 3 FRAME HEADER ...............................................................................
MCP Serial Transport Protocol Error Recovery ................................................................................................................................... 36 Chaining Data..................................................................................................................................... 38 Service Indications ............................................................................................................................. 39 SECTION 5. USB...................
SECTION 1. OVERVIEW This document describes the common format of the serial transport frames and defines the protocol for using these frames. This protocol can work as is with a RS-232 interface. However, the protocol needs to be adapted slightly to work with a USB interface. The USB section of this document explains how to adapt this protocol to work with a USB interface.
MCP Serial Transport Protocol 2
SECTION 2. TRANSPORT FRAME FORMAT COMMON FRAME FORMAT DEFINITION Below is the diagram of the common frame format: DA SA PCB LEN HEDC DATA EDC The frame consists of a frame header, a variable-size opaque data field and an error detection code (EDC).
MCP Serial Transport Protocol Protocol Control Byte The protocol control byte (PCB) provides information about the frame type, EDC protection used, chaining and sequencing. Below is the diagram of the PCB: 7 6 5 4 3 2 1 0 FT FT – – – – – – MSB • FT LSB Frame Type (2 bits) The contents of the protocol control byte is dependent on the frame type.
Section 2. Transport Frame Format DATA FIELD The data field can be 0 – 65535 bytes in length. The contents of the data field depend on the frame type. R-frames do not use this field. S-frames use this field to carry information that is specific to the S-frame command. I-frames use this field to carry information that is transparent to this protocol. Details of this I-frame information are contained in the devices command reference manual.
MCP Serial Transport Protocol 6
SECTION 3. TRANSPORT FRAME TYPES I-FRAMES This section defines the I-frames used in the MCP communications protocol. An I-frame (information frame) carries an application message in the data field. Application messages are transparent to this protocol. Application messages are outside the scope of this document. This section defines the PCB and data fields of the I-frame.
MCP Serial Transport Protocol Send and receive sequence numbers (N(S), N(R)) The send sequence number, N(S), is the sequence number of the current I-frame sent by a node. The receive sequence number, N(R), is the sequence number expected in the next received Iframe. The N(R) sequence number allows a node to embed an acknowledgement (receipt) in an I-frame.
Section 3. Transport Frame Types R-FRAMES This section defines the R-frames. An R-frame (receipt frame) is used for the following purposes: • • for conveying positive or negative acknowledgement about received I-frames for requesting a receipt from another node (used for error recovery) R-frames must always use the 8-bit LRC error detection method for the entire frame. This section defines the PCB and data fields of the R-frame.
MCP Serial Transport Protocol Receive Sequence Number (N(R)) The receive sequence number indicates what the next expected sequence number is, confirming all received I-frames with lower sequence numbers (in this case, no more than one). This is used to acknowledge received I-frames. This is the same as the receive sequence number used in Iframes. Data Field The data field is not used for R-frames and should remain empty.
Section 3. Transport Frame Types S-FRAMES This section defines the S-frames used in the MCP communications protocol. An S-frame (supervisory frame) is used for transmission control; this includes resynchronization, exchanging communication parameters between nodes, error recovery and flow control. S-frames must always use the 8-bit LRC error detection method for the entire frame. This section defines the S-frame PCB, data field and the transmission control commands.
MCP Serial Transport Protocol Request S-frames are sent by a node to request a specific transmission control operation to be performed by the destination node. The destination node replies with a response S-frame within a pre-determined amount of time. The response S-frame always has the same command code as the request S-frame.
Section 3. Transport Frame Types Resynchronize Protocol Command Command Code: 0 (0000) S-frame Type: Request/Response Request PCB: 90 (Hex) Response PCB: A0 (hex) Description: This request is used to resynchronize the protocol as part of error recovery (e. g., unrecoverable sequence errors, retries exceeded, etc.). The transport may also use this at the beginning of the session to initialize the sequence numbers of the device.
MCP Serial Transport Protocol Reset Device Command Command Code: 1 (0001) S-frame Type: Request/Response Request PCB: 91 (Hex) Response PCB: A1 (hex) Description: This command requests a device to reset itself to its power up state. The device should reset itself only after it sends the response. The device will not be able to communicate while it is resetting itself. After the device is reset, the transport will have to reestablish communications with the device.
Section 3. Transport Frame Types Get Communication Parameters Command Command Code: 2 (0010) S-frame Type: Request/Response Request PCB: 92 (Hex) Response PCB: A2 (hex) Description: This command requests the value of one of the devices communication parameters. Request Data: The parameter ID is located in the first byte of the data field.
MCP Serial Transport Protocol Model Number Parameter Parameter ID: 01 (Hex) Description: This parameter is not supported. Serial Number Parameter Parameter ID: 02 (Hex) Description: This parameter is not supported. Application Message Maximum Response Time Parameter ID: 03 (Hex) Description: This parameter is not supported. Block Wait Timeout (BWT) Parameter Parameter ID: 04 (Hex) Description: This parameter is used to determine what block wait timeout value the device is using.
Section 3. Transport Frame Types Set Communication Parameters Command Command Code: 3 (0011) S-frame Type: Request/Response Request PCB: 93 (Hex) Response PCB: A3 (hex) Description: This command sets the value of one of the devices communication parameters. Request Data: Parameter ID Value Response Data: Result Code Block Wait Timeout (BWT) Parameter Parameter ID: 04 (Hex) Description: This parameter is used to set the block wait timeout value the device is using.
MCP Serial Transport Protocol Frame Reject Command Command Code: 5 (0101) S-frame Type: Indication PCB: 85 (Hex) Description: The frame reject command is used to notify another node on the network that a frame they sent was not valid (e.g. unsupported EDC type). Frame rejection is used on frames that are understood by the receiver but contain unsupported types or data. For example, the frame may specify an unsupported frame type or may contain an invalid status code.
Section 3. Transport Frame Types Baud Synchronization Command Command Code: 6 (0110) S-frame Type: Request/Response Request PCB: 96 (Hex) Response PCB: A6 (hex) Description: This command is used by the host to synchronize the transmission speed on mediums with variable communication speed (i.e., serial ports). A response indicates that the device is synchronized with the transport. If the device synchronizes, it will take no longer than 75ms to respond to this request.
MCP Serial Transport Protocol Echo Command Command Code: 7 (0111) S-frame Type: Request/Response Request PCB: 97 (Hex) Response PCB: A7 (hex) Description: When a node receives this command it should echo back the data portion of the request message in the data portion of the response message. This command is used for testing purposes. For example, it can be used to check if a node is present and operational. Request Data: A maximum of 16 bytes of data.
Section 3. Transport Frame Types Description: The frame resend indication is used to notify a node that one of its frames was received with data errors. The node may either ignore this indication or resend the specified frame. The frame resend command is an indication. It does not require a response from the recipient. If a node decides to respond to the indication, it must resend the frame identified by the PCB in the indication. The error type is provided only for diagnostic purposes.
SECTION 4. PROTOCOL This section describes the protocol used for nodes to communicate using the frame formats and S-frame command described previously. PARAMETERS After two nodes are synchronized and before they begin exchanging frames, the nodes must retrieve any required communication parameters from each other. The Supported EDC Type parameter is an example of a parameter that may be desired. For a complete list of the supported parameters, see the S-frame Get Communication Parameters command.
MCP Serial Transport Protocol R-frame to I-frame Delay Due to limited resources in MagTek's RS232 and USB MCP devices, there is a limitation when receiving back to back packets. This affects the MCP protocol only in the following way. The device requires that the host delay a minimum of 50ms, after sending an R-frame, before sending the next I-frame. This issue can be handled robustly by doing the following.
Section 4. Protocol GENERAL PROCEDURES During the protocol, any node may send a frame at any time, regardless of whether it has received a frame or not. The frame may either be an I-frame, R-frame or S-frame. Every I-frame carries its send sequence number (N(S)). The I-frames sent by any two nodes are counted independently of each other. N(S) is counted modulo 2 and is coded by one bit.
MCP Serial Transport Protocol RESYNCHRONIZATION Resynchronization of the protocol may be attempted at three consecutive levels. If one level is unsuccessful, then the next level is tried: 26 • For the host: 1. retransmission of frames 2. use of S(RESYNC request) 3. device reset or deactivation • For the device: 1. retransmission of frames 2. use of S(RESYNC request) 3.
Section 4. Protocol RULES Service Requests Rule 1.1 A node can send a service request (S-frame request) at any time. The node shall not send another service request until it receives the service response or the block wait timeout expires. Rule 1.2 A node that receives an S-frame request shall respond with an S-frame response. If the node does not recognize the command ID or any of the parameters, the response shall contain the “not supported” result code. Rule 1.
MCP Serial Transport Protocol Rule 2.3 A node that sends a BAUD_SYNC request shall continue sending BAUD_SYNC requests until (a) it receives a valid response or (b) 2.5 seconds expire, whichever occurs first. The requests shall be sent 75-125 milliseconds apart. Establishing and Resetting a Connection Rule 3.1 Nodes shall establish connection prior to exchanging user data. Only one connection may exist between any two nodes. Rule 3.
Section 4. Protocol Rule 3.7 A node can accept the connection reset by sending RESYNC response according to Rule 3.3. Any outstanding unconfirmed I-frames shall be considered not transmitted successfully before the RESYNC response is sent. Data Transfer Rule 4.1 A node can send user data in an I-frame at any time when the connection is established and there is no outstanding, unconfirmed I-frame sent by this node to the destination node. Rule 4.
MCP Serial Transport Protocol Rule 4.7 A valid response to an I-frame is sending an R-frame with node’s current receive sequence number in the frame’s N(R) field. Rule 4.8 When a node that is awaiting response to its I-frame receives a valid response that contains N(R) field that is equal to the node’s send sequence number plus one, the node shall increment its send sequence number and consider the user data successfully transferred. Rule 4.
Section 4. Protocol Rule 5.5 A node that initiated error recovery per Rule 5.2 (using R-frame with poll bit set) processes the next received R-frame or I-frame the following way: (a) if the N(R) field of the received frame is equal to the node’s last sent N(S) plus one, then the node accepts this as confirmation according to Rule 4.8; otherwise (b), it re-sends the outstanding I-frame and again starts waiting for the response.
MCP Serial Transport Protocol Rule 6.2 If a node receives a RESEND S-frame indication for an outstanding I-frame and the PCB enclosed in the RESEND indication matches the PCB of the outstanding I-frame, the node shall either (a) ignore the indication or (b) initiate error recovery immediately, without waiting for the block wait timeout to expire. Rule 6.
Section 4. Protocol SCENARIOS This section describes different scenarios to illustrate how the protocol works in various situations. The scenarios include not only how to exchange various frames but also illustrates how a node performs error detection and error recovery. Each scenario is provided with a short description and a list of the protocol rules (defined above) that apply to the situation.
MCP Serial Transport Protocol Service Request Error Handling – no response ÆÆÆ (bwt) ÆÆÆ S (echo req) (bwt) ÆÆÆ S (echo req) (bwt) (request aborted according to Rule 1.4b) S (echo req) (Rule 1.1) (Rule 1.4) (Rule 1.4a) Baud Synchronization Typical Baud Synchronization ÆÆÆ (Rule 2.1) (100 msec) S (baudsync req) ÆÆÆ (Rule 2.3) (100 msec) S (baudsync req) ÆÆÆ (Rule 2.3) ÅÅÅ S (baudsync rsp) (Rule 2.2) (baud syncronization completed according to Rule 2.
Section 4. Protocol Resetting a Connection (connection was established and some data may have been exchanged) ÆÆÆ I (0,0) (Rule 4.1) ÅÅÅ R (1) (Rule 4.7) ÆÆÆ S (resync req) (Rule 3.6) ÅÅÅ S (resync rsp) (Rule 3.7) ÆÆÆ I (0,0) (Rule 4.1) ÅÅÅ R (1) (Rule 4.7) Data Transfer Data Transfer Using Minimum Number of Frames (connection was established and some data may have been exchanged) ÆÆÆ I (0,0) (Rule 4.1) ÅÅÅ I (0,1) (Rule 4.6) ÆÆÆ I (1,1) (Rule 4.6) ÅÅÅ I (1,0) (Rule 4.6) ÆÆÆ (Rule 4.
MCP Serial Transport Protocol Error Recovery Error Recovery Using R-poll – data frame lost (connection was established and some data may have been exchanged) I (0,0) (Rule 4.1) ÆXÆ (bwt) ÆÆÆ R (0)-poll (Rule 5.2) ÅÅÅ R (0) (Rule 5.4a) ÆÆÆ I (0,0) (Rule 5.5b) ÅÅÅ R (1) (Rule 4.7) (data is transferred successfully according to Rule 4.8) Error Recovery Using R-poll – response frame lost (connection was established and some data may have been exchanged) ÆÆÆ I (0,0) (Rule 4.1) (Rule 4.
Section 4. Protocol Error Recovery – intermediate data received (connection was established and some data may have been exchanged) I (0,0) (Rule 4.1) ÆXÆ ÅÅÅ I (0,0) (Rule 4.1) ÆÆÆ R (1) (Rule 4.7) (bwt) (bwt from the first I-frame) ÆÆÆ R (1)-poll (Rule 5.2) ÅÅÅ R (0) (Rule 5.4a) ÆÆÆ I (0,1) (Rule 5.5b) ÅÅÅ R (1) (Rule 4.7) (data is transferred successfully according to Rule 4.
MCP Serial Transport Protocol Repeating Baud Synchronization Upon Failure of Error Recovery (connection was established and some data may have been exchanged) ÆÆÆ I (0,0) (Rule 4.1) (bwt) ÆÆÆ R (0)-poll (Rule 5.2) (bwt) ÆÆÆ R (0)-poll (Rule 5.6a) (bwt) ÆÆÆ R (0)-poll (Rule 5.6a) (bwt) (data transfer fails according to Rule 5.6b) S (baudsync req) ÆÆÆ (Rule 5.8c and Rule 2.3) ÅÅÅ S (baudsync rsp) (Rule 2.2) ÆÆÆ S (resync req) (Rule 5.8c and Rule 3.6) ÅÅÅ S (resync rsp) ( Rule 3.7) ÆÆÆ I (0,0) (Rule 4.
Section 4. Protocol Error Recovery During Chain I (0,0)-C I (1,0)-C R (0)-poll I (1,0)-C I (0,0)-C I (1,0) ÆÆÆ ÅÅÅ ÆXÆ (bwt) ÆÆÆ ÅÅÅ ÆÆÆ ÅÅÅ ÆÆÆ ÅÅÅ ÆÆÆ ÅÅÅ R (1) R (1) R (0) R (1) R (0) (Rule 4.1) (Rule 4.7) (Rule 4.1) (Rule 5.2) (Rule 5.4a) (Rule 5.5b) (Rule 4.7) (Rule 4.1) (Rule 4.7) (Rule 4.1) (Rule 4.7) Service Indications Resend Indication on I-frame – indication ignored (connection was established and some data may have been exchanged) I (0,0) (Rule 4.1) ÆEÆ ÅÅÅ S (resend ind) (Rule 6.
MCP Serial Transport Protocol Resend Indication on S-frame – indication processed S (echo req) S (echo req) S (echo req) 40 ÆEÆ ÅÅÅ ÆÆÆ ÅXÅ (bwt) ÆÆÆ ÅÅÅ S (echo rsp) (Rule 1.1) (Rule 6.1) (Rule 6.3b and Rule 1.4a) (Rule 1.2) S (echo rsp) (Rule 1.4a) (Rule 1.
SECTION 5. USB This protocol can work as is with a RS-232 interface. However, the protocol needs to be adapted slightly to work with a USB interface. This section explains how to adapt this protocol to work with a USB interface. Everything mentioned in the preceding sections apply to the USB interface except what is pointed out in this section. The serial transport protocol is effectively “tunneled” over the USB. The baud synchronization S-frame command is not used with USB.
MCP Serial Transport Protocol Each model device shall use a different product identifier. The product identifier can usually be found in the device’s technical reference manual. All devices shall contain a manufacturer string descriptor with a value of “MagTek”. All devices shall contain a product string descriptor with a value that contains the model of the device. The product string value can usually be found in the device’s technical reference manual.
