Protocol Operations#

This section describes how the ASH protocol sends and receives frames, including the method used to achieve binary data transparency.

Sending Frames#

Before ASH sends a DATA frame, it performs this series of steps:

  1. The Control Byte is added before the Data Field. The frmNum field is set to the last frame transmitted plus one, and the ackNum field is set to the number of the next frame expected to be received. The reTx flag is clear.

  2. The Data Field is exclusive-OR’ed with a pseudo-random sequence (see Data Randomization).

  3. The two-byte CRC of the Control Byte plus the Data Field is computed and appended after the Data Field.

  4. The frame is byte stuffed to remove reserved byte values (see Reserved Bytes and Byte Stuffing).

  5. A Flag Byte is added after the CRC.

If a DATA frame is retransmitted, the process is the same except for step 1. The frmNum field retains the same value as when the frame was first transmitted, and the reTx bit is set. The ackNum is the current value as in normal transmission.

Other frame types omit step 2 and have differently formatted Control Bytes, but otherwise they use the same process.

Reserved Bytes and Byte Stuffing#

ASH reserves certain byte values for special functions. If bytes with these values happen to occur within a frame, ASH uses a process known as byte stuffing to replace those bytes so they have non-reserved values. Byte stuffing is performed on the entire ASH frame except for the Flag Byte. The receiver reverses the process to recover the original frame contents.

The following table lists the byte values that are reserved in ASH.

Value Special Function
0x7E Flag Byte: Marks the end of a frame. When a Flag Byte is received, the data received since the last Flag Byte or Cancel Byte is tested to see whether it is a valid frame.
0x7D Escape Byte: Indicates that the following byte is escaped. If the byte after the Escape Byte is not a reserved byte, bit 5 of the byte is complemented to restore its original value. If the byte after the Escape Byte is a reserved value, the Escape Byte has no effect.
0x11 XON: Resume transmission. Used in XON/XOFF flow control. Always ignored if received by the NCP.
0x13 XOFF: Stop transmission. Used in XON/XOFF flow control. Always ignored if received by the NCP.
0x18 Substitute Byte: Replaces a byte received with a low-level communication error (e.g., framing error) from the UART. When a Substitute Byte is processed, the data between the previous and the next Flag Bytes is ignored.
0x1A Cancel Byte: Terminates a frame in progress. A Cancel Byte causes all data received since the previous Flag Byte to be ignored. Note that as a special case, RST and RSTACK frames are preceded by Cancel Bytes to ignore any link startup noise.

To byte stuff, an Escape Byte is sent first, followed by the reserved byte being escaped with bit 5 of the reserved byte inverted. When a frame is received, byte stuffing is reversed to restore the original data.

Note: The Escape, Substitute, and Cancel Bytes are not the same as the ESC, SUB, and CAN ASCII control characters.

The following list illustrates some examples of possible byte stuffing:

  • Flag Byte 7E is sent as 7D 5E

  • XON Byte 11 is sent as 7D 31

  • XOFF Byte 13 is sent as 7D 33

  • Substitute Byte 18 is sent as 7D 38

  • Cancel Byte 1A is sent as 7D 3A

  • Escape Byte 7D is sent as 7D 5D

The byte value 0xFF has a special meaning when it occurs between ASH frames in ASH versions that allow sleeping by the NCP. (Within a frame, 0xFF is not special and does not need to be escaped.) 0xFF is sent by the Host to wake the NCP, and is echoed back when the NCP wakes up. The NCP can also wake the Host by sending 0xFF, although the Host does not echo it back to the NCP.

EmberZNet Serial Protocol (EZSP) on the NCP may also send a 0xFF byte to inform the host that it has a callback pending while it is operating in the synchronous (polled) callback mode.

Data Randomization#

If a DATA frame contains many reserved bytes, byte stuffing can nearly double the length of the frame. To make this less likely, a DATA frame’s Data Field is exclusive-OR’ed with the output of a pseudo-random sequence before byte stuffing. The Data Field is restored by exclusive-OR’ing again at the receiver.

The pseudo-random sequence is reinitialized at the start of every Data Field and is generated by an 8-bit linear feedback shift register described by the following bitwise equations:

  • rand0 = 0x42

  • if bit 0 of randi is 0, randi+1 = randi >> 1

  • if bit 0 of randi is 1, randi+1 = (randi >> 1) ^ 0xB8

The sequence starts {0x42, 0x21, 0xA8, 0x54, 0x2A, …}.

Receiving Frames#

When data is received, first any byte stuffing is reversed by inverting bit 5 of bytes following Escape Bytes. The Control Byte, the first byte received in a frame, is saved, and if the buffer memory is available, the following Data Field bytes are stored. Regardless of buffer availability, the frame’s length and CRC are computed as data is input. If a Cancel Byte or Substitute Byte is received, the bytes received so far are discarded. In the case of a Substitute Byte, subsequent bytes will also be discarded until the next Flag Byte.

Normally, a Flag Byte marks the end of a frame, which is then validated. To be valid, a frame must:

  • Have a correct CRC.

  • Have a Control Byte corresponding to a valid frame type:

  • On the Host: DATA, ACK, NAK, RSTACK, or ERROR

  • On the NCP: DATA, ACK, NAK, or RST

  • Have a valid Data Field length for the frame type.

  • Have a valid ackNum if in the CONNECTED state and the frame type is DATA, ACK, or NAK.

A frame that fails any of these criteria is discarded. If ASH is in the CONNECTED state and the Reject Condition is not already set, the Reject Condition is set and a NAK is sent. This is also done if a Substitute Byte was received within a frame.