The handling of link errors by the link state machine is described in the section “Link Error Handling“. This section considers what happens to a packet that is travelling across a link when an error occurs.

If an error is detected by a link interface, the following sequence of events takes place to recover from the error:

1. Detect Error

A Disconnect, Parity, Escape, or Credit error is detected.

Figure 46 shows the two directions of the link transferring packets, from an end user buffer passing data to the SpaceWire transmitter, via the SpaceWire interface transmit FIFO, across the link, into the SpaceWire interface receive FIFO at the other end of the link, and on into the end user buffer taking data from the receiver. In the left to right direction of the link the head of a packet is in the receive user buffer and the tail of the packet with the EOP is in the transmit end user buffer. An error has just occurred in this direction of the link.

Link Error Recovery: Error Detection

Figure 46 Link Error Recovery: Error Detection

2. Disconnect Link

The error detected in the receiver on the right hand side of Figure 46, causes the transmitter at that end to disconnect, resulting in a disconnect error occurring at the other end of the link. Both ends of the link are now disconnected as illustrated in Figure 47.

Link Error Recovery: Link Disconnection

Figure 47 Link Error Recovery: Link Disconnection

3. Terminate Packets with EEPs

The information in the receive FIFOs has an EEP appended to it, as soon as there is room in each FIFO to add one. This terminates the received part of the packet, so that it can continue on its way through the SpaceWire network. This is illustrated in Figure 48.

Link Error Recovery: Terminate Packets with EEPs

Figure 48 Link Error Recovery: Terminate Packets with EEPs

4. Spill Rest of Packet

The remainder of the packet which has not yet been transferred across the link has to be discarded, since one or more N-Chars will have been lost or corrupted due to the error on the link. The tail end of the packet that has not yet been sent across the link contains valid data, but its destination is not clear: for example, it could have been an EOP that was lost when the error occurred on the link. Since the destination is unknown all that can be done with the tail end of the packet is to discard it. Data is read by the transmitter and spilt until the EOP (or EEP) is reached. The character following the EOP will be the destination address at the start of the next packet. The result after spilling the packet is shown in Figure 49.

Link Error Recovery: Spill Rest of Packet

Figure 49 Link Error Recovery: Spill Rest of Packet

5. Reconnect

Now the SpaceWire link has tidied up after the error, the link can be re-initialised and the connection re-established. This is shown in Figure 50.

Link Error Recovery: Reconnect

Figure 50 Link Error Recovery: Reconnect

6. Continue Packet Transfer

With the link restarted the next packet, whose head and destination address is waiting in the transmit FIFO, can be sent. Normal operation has resumed. This is shown in Figure 51.

Link Error Recovery: Continue Operation

Figure 51 Link Error Recovery: Continue Operation

The error recovery mechanism works across networks comprised of a number of routing switches. Only the link on which the error occurs is reset (disconnect/reconnect). All the other links continue operation. Normally only the packet in which the error occurred is partly lost and all other packets remain valid. In some cases more than one packet can be lost due to the time taken for link disconnection.

If the header byte (i.e. first byte after an EOP or EEP) is corrupted, the entire packet is lost and the data is not propagated across a network. The routing switch simply disposes of the packet.

If the error occurs in a EOP (or EEP), two packets are affected: the one before the EOP where all the data is sent but no EOP is received, and the following one because the link transmitter “spills” the packet until the next EOP (or EEP).

If the error occurs in a NULL or FCT inserted in the data stream for a packet, the packet being sent is discarded from that point on. This is because it is not known what the character was before it was corrupted.

The time taken for complete recovery from the error on the link will depend upon how long it takes to spill the tail end of the packet being transferred when the link error occurred, which depends on the size of that packet. The tail may have to be pulled out from the packet source, through one or more routers making up a SpaceWire network as it is being split.

The decision about what to do with the packet that terminates with the EEP is up to the user application.