CONNECTED State#
The Host initializes the ASH protocol by resetting the NCP through either the nRESET pin or sending the RST frame. When the NCP is fully booted and ready to interact with the Host, the NCP will send the RSTACK frame to the Host.
Due to possible I/O buffering, it is important to note that the Host could receive several valid or invalid frames after triggering a reset of the NCP. The Host must discard all frames and errors until a valid RSTACK frame is received. The Host must also allow a certain amount of time to receive the RSTACK frame; the parameter T_RSTACK_MAX defines this timeout. If the Host does not receive the RSTACK frame within the timeout period, the Host should retry the reset process up to five times in case of noise interfering with the RST or RSTACK frames.
When a RSTACK frame is received, the Host must perform a final verification of the Version number provided in the RSTACK’s Data Field. If the Version number being supplied by the NCP is compatible with the Host’s version number for ASH, the Host and the NCP have successfully transitioned into the CONNECTED state and can begin to exchange EZSP messages.
Frame Numbers#
ASH uses 3-bit frame numbers to track reception of DATA frames and detect when a frame is lost in transmission. The bit fields labeled frmNum in the Control Byte of DATA frames are numbered sequentially by the sender, 0 through 7 and back to 0, and the receiver expects to get consecutively numbered frames.
Both the NCP and the Host maintain two frame numbers, because the frame numbers for data sent from the Host to the NCP are independent of those sent from the NCP to the Host. Thus the frmNum field in a DATA frame belongs to the sequence number in one direction, and the ackNum field in a DATA, ACK, or NAK frame belongs to the sequence number in the reverse direction.
The Host and the NCP maintain a sliding window for DATA frames, and this window must be smaller than the 8 frames allowed by the 3-bit frame number field. The effect of the sliding window is that a sender may transmit multiple frames before receiving an acknowledgement, and the window’s smaller size means that neither side has to worry about the frame numbers wrapping and mistakenly acknowledging the wrong frame.
Acknowledgements and Frame Numbers#
The ackNum field in DATA, ACK, and NAK frames acknowledges received DATA frames. Note that ackNum is the number of the next frame the receiver expects and it is one greater than the last frame received.
The NCP discards any frames it receives that have an invalid ackNum value. A valid ackNum is a number between the last received ackNum and the last transmitted frmNum plus one, where both limits are inclusive.
The maximum number of frames a sender can transmit without them being acknowledged is the window size, which is specified by the parameter TX_K. When a sender has TX_K unacknowledged frames, it may not send any more, although it may retransmit frames if needed.
Piggybacked Acknowledgements#
The NCP, but not the Host, may “piggyback” acknowledgements on a DATA frame. This is more efficient than sending a separate ACK frame, but if there is no DATA frame ready to send, the NCP will send an ACK frame instead. The NCP delays sending an ACK after it receives a DATA frame. This delay increases the likelihood that an acknowledgement is piggybacked on a DATA frame or multiple acknowledgements are sent with one ACK frame. The ACK delay parameter, T_TX_ACK_DELAY, is the artificial delay that specifies how long to wait before sending an ACK frame when there is no DATA frame to send.
The Host may not piggyback acknowledgments and should promptly send an ACK frame when it receives a DATA frame. The NCP will normally reject DATA frames received with piggybacked ACKs because it is not able to buffer them.
Sending DATA Frames#
A given DATA frame can be sent if there is no higher priority ACK or NAK frame to be transmitted, the number of frames already transmitted without being acknowledged is not at the window size limit, and the receiver is ready to accept the frame. When first sent, the frmNum bit field is assigned the next consecutive frame number, and its ackNum bit field is set to the frame number of the next frame expected to be received. The Data Field is then exclusive-OR’ed with a pseudo-random sequence. Finally, the entire frame, excluding the Flag Byte, is byte stuffed.
After the DATA frame has been written to the UART buffer, it is saved on an ASH queue so that it can be retransmitted if required. When a frame is acknowledged, it is deleted from the queue. If an acknowledgement is not received in time, the frame will be retransmitted.
Receiving DATA Frames#
The Data Field of a DATA frame is only passed up to EZSP if it is valid, in sequence, and there is enough memory to buffer the data. Before passing the data to EZSP, the data is exclusive-OR’ed with the pseudo-random sequence to restore the original contents. The ackNum field is always processed, because this information is separate from the Data Field or frmNum. Even if the DATA frame is discarded due to being a duplicate, out of sequence, or lack of memory, the ackNum field is still valid and will be processed to update the acknowledged frames.
DATA frame Acknowledgement timing#
The NCP adjusts the time allowed to receive an acknowledgement for a DATA frame based on how long it has taken to receive previous acknowledgements. In general, the NCP waits four times the rolling average of measured acknowledgement times before timing out. Note that a DATA frame may be acknowledged by the ackNum bit field in an ACK, NAK, or DATA frame.
Three parameters govern computing the DATA frame acknowledgement timeout: t_rx_ack: T_RX_ACKINIT, T_RX_ACK_MIN, and T_RX_ACK_MAX. These are the initial, the minimum, and the maximum values, respectively, that are assigned to t_rx_ack.
At startup, t_rx_ack is set to T_RX_ACK_INIT. Whenever an acknowledgement is received, t_rx_ack is set to 7/8 of its current value plus 1/2 of the measured time for the acknowledgement. Therefore, over time t_rx_ack equals four times the time-weighted average of actual acknowledgement times. If a DATA frame acknowledgement is not received within the current timeout value, then t_rx_ack is doubled. The value of t_rx_ack is always limited to the range from T_RX_ACK_MIN to T_RX_ACK_MAX.
If a frame is not acknowledged within t_rx_ack, it times out and the NCP will retransmit the frame. If there are enough consecutive timeouts, the NCP enters the ERROR state. The maximum number of consecutive timeouts is given by the parameter ACK_TIME-OUTS.
DATA Frame Flow Control#
The Host uses DATA frame flow control to throttle the transmission of DATA frames from the NCP, but the NCP does not control Host transmissions to it. NCP DATA frames are either responses to EZSP commands or callbacks that are sent without being requested by the Host. DATA frame flow control applies only to callback DATA frames, and does not stop the NCP from sending command response DATA frames.
When the Host is not ready to accept additional callback DATA frames because it does not have enough free buffers to store them, it instructs the NCP to pause callback DATA frame transmission by sending an ACK or NAK frame with the nRdy (not ready) flag set to 1. When callback DATA frame transmissions are paused, the NCP is still allowed to transmit ACK and NAK frames, transmit command response DATA frames, and retransmit callback DATA frames if required to recover from errors. When the Host is ready again, it sends an ACK or NAK with nRdy set to 0.
After it receives an ACK or NAK with nRdy set, the NCP may not transmit a callback DATA frame for a period of time defined by the parameter T_REMOTE_NOTRDY. As long as the Host remains in the not ready state, the Host sends an ACK or NAK frame with the nRdy flag set at intervals of time defined by the parameter T_LOCAL_NOTRDY. The NCP may resume sending callback DATA frames if it does not receive another ACK or NAK with the nRdy flag set after the period T_REMOTE_NOTRDY has elapsed. This prevents the NCP being held off indefinitely if an ACK or NAK with the nRdy flag cleared is lost.
DATA frame flow control does not eliminate the need for low-level (RTS/CTS or XON/XOFF) flow control. Low-level flow control helps ensure that serial data is not lost at the UART due to overruns or overflows, while DATA frame flow control operates at the ASH level and prevents loss of DATA frames due to lack of buffer memory.
Data Exchange Example#
The following figure illustrates a simple timeline providing an example of basic DATA and ACK frame usage and the sequence numbering involved.
The Host sends a DATA frame with frmNum 0 to the NCP.
The NCP has no data ready to send, so it replies with an ACK frame with ackNum 1, the next frame the NCP expects to receive.
The Host has more data to send, so it sends DATA frame with frmNum 1 before it receives the ACK frame. The Host now has two unacknowledged frames outstanding.
The NCP has data to send, so it sends its DATA frame with frmNum 0 and ackNum 2 piggybacked on the DATA frame as an acknowledgement of the Host’s DATA frame 1.
The Host has no further data to send, so it sends just an ACK for the frame the Host just received.
Reject Condition and NAK Frames#
ASH sets the Reject Condition after receiving a DATA frame with any of the following attributes:
Has an incorrect CRC.
Has an invalid control byte.
Is an invalid length for the frame type.
Contains a low-level communication error (e.g., framing, overrun, or overflow).
Has an invalid ackNum.
Is out of sequence.
Was valid, but had to be discarded due to lack of memory to store it.
A frame is out of sequence if its frmNum is not one greater than the last (non-retransmitted) frame received. (Remember that sequence numbers are 3 bits and the modulo 8 operation means 0 is the number after 7.) Retransmitted frames are never considered out of sequence.
If the Reject Condition is set when it is currently clear, a NAK frame is sent. The Reject Condition is cleared as soon as a valid, in-sequence DATA frame is received and can be buffered.
When a NAK is received, the receiver of the NAK begins retransmitting if it is not already doing so, assuming it has transmitted any frames that have not been acknowledged. If a new DATA frame is in the process of being sent, the new DATA frame transmission is cancelled by sending a Cancel Byte because it would be discarded as out of sequence anyway, and retransmission is started more quickly this way.
Retransmitting#
A DATA frame can be retransmitted for one of two reasons:
The DATA frame was not acknowledged within the allowed time.
A NAK was received indicating that the DATA frame was not received correctly.
Retransmission begins with the oldest unacknowledged frame, and all retransmitted frames are flagged by setting the reTx flag in the Control Byte. A retransmitted frame keeps the same frmNum as when first transmitted, but the ackNum bit field may differ if the sender has received more DATA frames since it was first transmitted.
If the sender receives an acknowledgement for a frame due to be retransmitted, that frame will not be retransmitted. When done retransmitting, the sender resumes sending new DATA frames again.
Upon receiving a retransmitted frame, the receiver sends an immediate ACK. The receiver does not set the Reject Condition or send a NAK when a retransmitted frame is received. If the retransmitted frame was previously received correctly, the Data Field is discarded and the ackNum is processed as usual.
In the example shown in the following figure, the second DATA frame sent by the NCP is lost, and this is detected by the Host when it receives an out-of-sequence frame. At this point the Host sends a NAK and sets its Reject Condition. Meanwhile, another DATA frame is being sent by the NCP, and when the Host receives this, it is also out of sequence; however, since the Reject Condition is already set, the Host does not send another NAK.
When the NCP receives the NAK, the NCP begins retransmitting starting from its oldest unacknowledged frame. When the Host receives the first in-sequence frame, it clears the Reject Condition and sends an ACK. Finally, the NCP finishes sending all of the unacknowledged frames and the NCP clears the Retransmit Condition, resuming transmission of new data frames.
In the simple example illustrated in the following figure, the Host did not send any DATA frames to the NCP, but it could have been sending DATA frames throughout the error recovery process. ASH data transfer, error detection, and error recovery operate independently and simultaneously in both directions.
