Introduction to the Xmodem protocol

1. Xmodem Agreement 1.1. Brief introduction

In the previous chapter, Bootloader and the app in the serial port upgrade actually used a file transfer protocol, that is, the Xmodem protocol, because of its simple, easy to implement and use the characteristics of many occasions have been widely used.

Xmodem was the protocol that was created by Ward Christensen in 1978 for modem correction, and it has actually become a standard. The packet size sent by the modulation dissolution regulator using this protocol is 128-byte (the packet size can also be 1K bytes). If the packet is successfully received, the receiver returns a positive response signal (ACK) and, if an error is found, returns a negative response signal (NAK) and sends the packet again. Xmodem uses parity as a method of error-checking control.

This protocol transmits data in 128-byte chunks, and each block uses a checksum procedure for error detection. If the receiver's checksum about a block is the same as it does in the sender's checksum, the receiver sends an acknowledgement byte to the sender. However, this strategy of endorsing each block will lead to low performance, especially when there is a long propagation delay in the case of a satellite connection, the problem is even worse.

A protocol corresponding to XMODEM using cyclic redundancy checks is called XMODEM-CRC. Another is xmodem-1k, which transmits data in a 1024-byte piece. Zmodem is the most effective version of Xmodem, and it does not need to be recognized for each block. In fact, it simply requires that the damaged block be re-sent. Zmodem is very useful for packet-switched networks that are charged by block. There is no need to endorse loopback groupings to a large extent reducing the amount of traffic.

Ymodem is also a kind of xmodem realization. It includes all the features of the xmodem-1k, plus the batch file transfer mode is added for sending a set of files during a single session.

1.2. The contents of the agreement are 1.2.1. Protocol-related control characters

SOH 0x01

STX 0x02

EOT 0x04

ACK 0x06

NAK 0x15

CAN 0x18

Ctrlz 0x1A

1.2.2. Standard frame Format (128 bytes)

SOH	Message packet number	The complement of the package number	Data segment	Checksum
Start byte	Package number	Take back plus 1	128	Data segments and

The 1k-xmodem frame format is as follows:

STX	Message packet number	The complement of the package number	Data segment	Checksum
Start byte	Package number	Take back plus 1	1024	Data segments and

Description

The opening byte of the SOH frame, which represents the first byte in the packet

Packet Sequence Number: to the 256 modulus to the current package number, the first packet is 1, and the packet sequence range 0~255;

The complement of the information packet ordinal: the complement of the current information packet number;

Data segment: The length of the data segment is fixed to 128 bytes (the last segment data byte count is certainly less than 128, populated by Ctrlz), its content is not any restriction, can be text data or binary data;

Arithmetic checksum: 1 bytes of arithmetic checksum, only after summing the data section to 256 modulo;

1.2.3. Transport logic

1> send and receive both sides dial-up connectivity, the sender waits for a NAK signal from the receiving party. When the first nak arrives, the sender interprets the first packet as starting to send;

2> when the sender receives the first NAK and initiates the transmission, the sender transmits the data in a frame format of 128 bytes each time, and waits for the receiver's acknowledgement signal;

3> the sender receives an ACK signal from the receiving party, explaining that the packet is properly received and has the meaning of sending the next packet;

4> the sender receives a NAK signal from the receiving party and interprets the request to resend the same packet;

The 5> sender receives the CAN signal from the receiving party and interprets it as a request to stop the transmission unconditionally;

6> the sender to complete the normal transmission of all data, need to end normally, send EOT signal to notify the receiver. The receiving party confirms with ACK;

7> receiver sends can unconditionally stop the transmission process, the sender receives can, does not send the EOT confirmation;

8> Although the packet is an SOH to mark the beginning of a packet, but the EOT in the SOH position indicates the end of the data transmission, there is no information sent over;

9> receiver should first confirm the integrity of the packet ordinal, by filling the packet ordinal, and then the complement of the message packet ordinal or, the result is 0 is correct, the result is not 0 send Nak request retransmission;

10> the receiver confirms that the packet number is correct, and then checks to see if the expected sequence number. If it is not expected to get the packet sequence number, indicating that a serious error occurred, should send a can to abort the transmission;

11> the only exception to the 10> situation is that the packets received are the same as the previous packet ordinal, in which case the receiver simply ignores the duplicate packet, sends an ACK to the sender, and prepares to receive the next packet.

12> the receiver confirms the integrity of the packet sequence and is expected to be correct, only the 128-byte data section is arithmetic and verified, and the result is compared with the last byte in the frame (arithmetic checksum), the same sends the ACK, different sends the NAK;

1.2.4. Timeout processing

The 1> receiver waits for a packet to arrive with a time-out time limit of 10 seconds, each timeout after sending a NAK;

2> when a packet is received, the time-out interval for each character in the receive process is 1 seconds;

3> to maintain "receiver driver", the sender should not use timeout processing while waiting for a boot byte

4> Once the transmission begins, the sender uses a separate 1-minute timeout period to give the receiver sufficient time to send ACK, NAK, can before the must be processed;

5> all timeouts and error events are retried at least 10 times;

1.2.5. Description of the Checksum

The XMODEM protocol supports 2 checksums, which are cumulative and with CRC checksum. When the receiver starts the transfer at the beginning, it sends a nak, indicating that it wants to be verified in addition and in a way. When the receiver starts the transmission at first, it sends the character "C", indicating that it wants to check it in CRC mode.

Some people may ask, how does the receiver want to verify that the sender has to cooperate, the sender must all support the cumulative and checksum CRC checksum? In fact, Xmodem requires support for CRC must also support the cumulative sum, if the sender only support the cumulative sum, and the receiver with the character "C" to start, then as long as the sender regardless of it, when the receiver continues to send "C", after three times did not receive the answer, will automatically change to send Nak, Since it has been understood that the sender may not support CRC verification, the receiver now changes to accumulate and verify the sender communication. The sender receives the NAK and sends a packet response.

1.2.6. xmodem-1k

xmodem-1k on the basis of the standard protocol, the size of the transmission packet (1K) is increased, and the CRC is added to improve the transmission reliability.

The difference is that when Xmodem is enabled, the receiver sends the C character. The sender receives a C character to be determined to take the xmodem-1k extension, otherwise, when the timeout occurs, it is transferred according to the basic version.

Introduction to the Xmodem protocol