Study 11 problems that must be viewed in the XMODEM protocol

As one of the main methods of serial data transmission, the XMODEM protocol may only have access to bootloader. The content of this Protocol on the internet is either in English or not detailed. I have studied 1k-xmodem before writing bootloader, and I have made many references. I would like to share with you my understanding of XMODEM!

1. What is the XMODEM protocol?
XMODEM is an asynchronous file transfer protocol widely used in serial communication. There are two types: Standard XMODEM and 1k-xmodem. The former transmits data in the form of 128 bytes, and the latter is 1 K, that is, 1024 bytes, each block uses a checksum process for error detection. During the verification process, if the receiver's checksum for a block is the same as the sender's checksum, the receiver sends an ACK message to the sender ). Because XMODEM needs to recognize each block, this will lead to a decline in performance, especially when the delay is relatively long, this protocol seems less efficient.
In addition to XMODEM, there are also ymodem and zmodem protocols. Their protocol content is similar to that of XMODEM. The difference is that ymodem allows batch file transmission, which is more efficient. zmodem is an improved XMODEM that only needs to resend damaged blocks, other correct blocks do not require confirmation bytes. Reduces traffic.
2. control characters related to the xmodem protocol
Soh 0x01
STX 0x02
EOT 0x04
Ack 0x06
Nak 0x15
Can 0x18
Ctrlz 0x1a
3. Standard XMODEM protocol (each packet contains 128 bytes of data) frame format
_______________________________________________________________
|
| Soh | Information Package number | supplemental code of the information package number | Data Segment | checksum |
| _____ | ____________ | _______________ | __________ | ____________ |
4.1k-XMODEM (each packet contains 1024 bytes of data) frame format
_______________________________________________________________
|
| STX | information package serial number | supplemental code of the information package serial number | Data Segment | checksum |
| _____ | ____________ | _______________ | __________ | ____________ |
5. Data Packet description
For the standard XMODEM protocol, if the transmitted file is not an integer multiple of 128, the valid content of the last packet must be smaller than the frame length. For the insufficient part, Ctrl-z (0x1a) is used). Someone may ask, if I transfer the. binfile generated by the bootloader project, what will happen if the MCU encounters the 0x1a character after receiving it? In fact, if the transfer is a text file, then the recipient is very easy to recognize the content received, because the CTRL-Z is not the first 128 ASCII code, not common visible characters, if it is a binary file, MCU does not actually execute it as code. Even in an Excel file, because it contains some internal structures that indicate the length of each field, it does not read any extra characters. Otherwise, the XMODEM is too weak. The same applies to 1k-xmodem.
6. How to start transmission?
Transmission is started by the receiver by sending "C" or Nak to the sender (note that the Nak mentioned here is used to start transmission. We can see below that Nak can also be used to generate retransmission mechanism for data ). The nak signal sent by the receiver indicates that the receiver intends to accumulate and verify the data; the "c" character indicates that the receiver wants to use CRC verification (the XMODEM source code is described below in the specific verification rules, and the source code is better than words ).
7. transmission process
When the first "C" or Nak sent by the receiver arrives at the sender, the sender considers that the first packet can be sent and the transmission has started. The sender should then add the header, package number, package number, and Package number of 128 bytes of data each time, and add the checksum at the end to package the data for transmission in the frame format.
After the sender sends the first packet, the sender waits for the confirmation byte ACK from the receiver. After receiving the ACK confirmation from the receiver, the sender considers that the packet is correctly received by the receiver and the receiver asks the sender to continue sending the next packet; if the sender receives the Nak (here, Nak is used to tell the sender to re-transmit, not to start transmission) bytes from the receiver, it indicates that the receiver requests to resend the data packet; if the sender receives the can byte from the receiver, it indicates that the receiver requests to stop transmission unconditionally.
8. How to End transmission?
If the sender normally transmits full data, the transmission ends. If the sender ends successfully, the sender needs to send an EOT byte notification to the receiver. The receiver replies with Ack for confirmation. Of course, the receiver can also force stop transmission. When the receiver sends a can byte to the sender, it indicates that the receiver wants to stop transmission unconditionally. After the sender receives the can, you do not need to send EOT confirmation (because the recipient does not want to handle it anymore ).
9. Special Handling
Although a data packet starts with an information packet using Soh, if EOT appears at the Soh position, the data transmission is complete and no data is transmitted.
The receiver should first confirm the integrity of the data packet sequence number. by completing the data packet sequence number, the result is 0, indicating that the data packet sequence number is correct, if the result is not 0, the Nak request will be re-transmitted.
After the receiver confirms that the data packet sequence number is correct, it then checks whether the sequence number is expected. If it is not the expected data packet sequence number, it indicates a serious error, you should send a can to stop the transmission.
If the number of packets received is the same as that of the previous packet, the receiver ignores the duplicate packet and sends an ACK to the sender to receive the next packet.
After the receiver confirms that the integrity and expectation of the information packet sequence number are correct, it only performs arithmetic and verification on the 128-byte data segment. The result is compared with the last byte (arithmetic checksum) in the frame, send the same ack and different NAKs.
10. checksum description
The XMODEM protocol supports two types of checksum, which are accumulate and CRC checksum.
When the receiver starts the transmission, it sends a Nak, indicating that it wants to accumulate and verify the data.
When the receiver starts transmission, the character "C" is sent, indicating that it wants to verify the data in CRC mode.
Someone may ask, how does the receiver verify that the sender must cooperate? Does the sender must support both the accumulate and CRC verification? In fact, if XMODEM requires support for CRC, it must support both the sum. If the sender only supports the sum, and the receiver starts with the character "C", the sender only needs to ignore it, when the receiver continues to send "c" and does not receive a response three times later, it will automatically send the Nak because it understands that the sender may not support CRC verification, now the receiver changes to accumulate and verify the sender's communication. The sender immediately sends a packet response when receiving the Nak.

Forgive address: http://blog.21ic.com/user1/1623/archives/2009/59858.html