XModem Protocol with CRC

Introduction

The Xmodem protocol was created years ago as a simple means of having two computers talk to each other. With its half-duplex mode of operation, 128- byte packets, ACK/NACK responses and CRC data checking, the Xmodem protocol has found its way into many applications. In fact most communication packages found on the PC today have a Xmodem protocol available to the user.

NOTE: Amulet uses a slightly modified 128-byte or 1K Xmodem (with 16-bit CRC) protocol. For 1k-Xmodem, the SOH byte is 0x02, and for 128-byte it is 0x01.

Theory of Operation

Xmodem is a half-duplex communication protocol. The receiver, after receiving a packet, will either acknowledge (ACK) or not acknowledge (NAK) the packet. The CRC extension to the original protocol uses a more robust 16-bit CRC to validate the data block and is used here. Xmodem can be considered to be receiver driven. That is, the receiver sends an initial character “C” to the sender indicating that it’s ready to receive data in CRC mode. The sender then sends a 133-byte packet, the receiver validates it and responds with an ACK or a NAK at which time the sender will either send the next packet or re-send the last packet. This process is continued until an EOT is received at the receiver side and is properly ACKed to the sender. After the initial handshake the receiver controls the flow of data through ACKing and NAKing the sender.

Table 1. XmodemCRC Packet Format

NOTE: Bytes 0-5 of each binary file are the flash header bytes. The Amulet uses these bytes to determine where to store the file within the flash. You can send the files in any order, the Amulet won't mind.

Definitions

The following defines are used for protocol flow control.

Byte 1 of the XmodemCRC packet can only have a value of SOH, EOT, CAN or ETB anything else is an error. Bytes 2 and 3 form a packet number with checksum, add the two bytes together and they should always equal 0xff. Please note that the packet number starts out at 1 and rolls over to 0 if there are more than 255 packets to be received. Bytes 4 - 131 form the data packet and can be anything. Bytes 132 and 133 form the 16-bit CRC. The high byte of the CRC is located in byte 132. The CRC is calculated only on the data packet bytes (4 - 131) .

Xmodem has a CRC, but there is an optional secondary CRC that checks the data that was actually written to the flash. After sending the EOT byte (0x04) after the last packet in each file, you can send what we have dubbed the EOTCRC (0x16) This will cause the Amulet color chip to calculate a new CRC based off of the data in the flash. A match is indicated by an ACK and a non-match by a NACK. The FSN will begin transmission after the ACK or NACK. A NACK'd file should be reprogrammed.

Synchronization

In the standard Xmodem Protocol, the receiver starts by sending an ASCII “C” (0x43) character to the sender indicating it wishes to use the CRC method of block validating. In Amulet's color chip, we will instead output a character that indicates the size of the serial dataflash connected to first chip select CS0 of the SPI bus. This character is reffered to as the Flash Size Notifier, or FSN. The flash size to character mapping is as follows:

a : 1Mbit
b : 2Mbit
c : 4Mbit
d : 8Mbit
e : 16Mbit
f : 32Mbit (standard starter kit size)
g : 64Mbit (GCC-2 size)
Z : None Detected

After sending the initial FSN character, the receiver waits for either a 2 second time out or until a buffer full flag is set. If the receiver is timed out then another FSN character or an ACK is sent to the sender and the 2 second time out starts again. This process continues until the receiver receives a complete 133-byte packet.

Receiver Considerations

This protocol NAKs the following conditions: 1. Framing error on any byte 2. Overrun error on any byte 3. Duplicate packet 4. CRC error 5. Receiver timed out (didn't receive packet within 1 second) On any NAK, the sender will re-transmit the last packet. Items 1 and 2 should be considered serious hardware failures. Verify that sender and receiver are using the samebaud rate, start bits and stop bits. Item 3 is usually the sender getting an ACK garbled and re-transmitting the packet. Item 4 is found in noisy environments. And the last issue should be self-correcting after the receiver NAKs the sender.

Sample crc calculation code

int calcrc(char *ptr, int count)
{
    int  crc;
    char i;

    crc = 0;
    while (--count >= 0)
    {
        crc = crc ^ (int) *ptr++ << 8;
        i = 8;
        do
        {
            if (crc & 0x8000)
                crc = crc << 1 ^ 0x1021;
            else
                crc = crc << 1;
        } while(--i);
    }
    return (crc);
}