1
Y Modem Protocol
X Modem is an early file transfer protocol. Y Modem is an improved version of X Modem, offering faster and more stable transmission. The term Y Modem generally refers to YModem-1K.
Figure 1 Y Modem Protocol Frame
The core differences between the two can be summarized in the table below:
Click to view the full image
2
Modifications to OTA Code Based on X Modem
Currently, the OTA code provided on the Renesas official website is based on the X Modem protocol (for example, the System_BootLoader project in the r20an0640ej sample program). To change it to the Y Modem protocol, modifications are needed in the transmission logic, verification logic, frame processing logic, etc.
01
Handshake Signal Adjustment
X Modem Handshake:
Typically, the receiver may initiate with a simple ACK or a specific character (for example, in some implementations, the receiver sends ‘C’ to indicate CRC16 verification), making the logic relatively simple.
Y Modem Handshake:
Must be initiated by the receiver sending YMODEM_C (character ‘C’, ASCII code 0x43). The sender will only start transmitting the initial frame (including filename and file size) after receiving this.
Modification Point:
Add a function void ymodem_send_c(void) to send the necessary 0x43 (‘C’) handshake signal for the Y Modem protocol, notifying the sender to transmit the initial frame.
02
Initial Frame Structure and Processing
X Modem Initial Frame:
Generally, it directly transmits data blocks without file information.
Y Modem Initial Frame:
The filename and file size must be included in the initial frame (transmitted as SOH with a length of 133 bytes, packet number fixed at 0x00, and packet number’s complement at 0xff).
Figure 2 Y Modem Initial Frame
Modification Point:
Define the Y Modem initial frame structure ymodem_start_frame_t
Modify the frame verification function uint8_t xmodem_check_frame(uint8_t* const p_xmodem_buff) to include verification logic for the initial frame format.
03
Data Frame Reception Processing
X Modem Data Frame:
The frame header is SOH (128-byte block) or STX (some derivative versions use 1024-byte blocks). The existing code uses SOH (128-byte block).
Y Modem Data Frame:
The frame header distinguishes between SOH (128-byte information block) and STX (1024-byte information block), and data must be filled according to the rules during transmission. For SOH frames, if the last packet is less than 128 bytes, it is padded with 0x1A, and the last frame length remains 133 bytes; for STX frames, if the last packet is less than or equal to 128 bytes, it is sent with a length of 133 bytes, and if it is greater than 128 bytes but less than or equal to 1024 bytes, it is sent with a length of 1029 bytes, with invalid data padded with 0x1A.
Figure 3 Y Modem Data Frame
Modification Point:
Modify uint8_t xmodem_check_frame(uint8_t* const p_xmodem_buff) to adjust the reception processing of data frames.
04
End Frame Processing
X Modem End Frame:
Generally, the EOT (0x04) character is sent, and the receiver responds with ACK to end the process.
Y Modem End Frame:
Uses an SOH 133-byte empty packet (data area, checksum, etc., filled with 0x00) as the end frame, requiring the construction of corresponding end frame sending logic:
Figure 4 Y Modem End Frame
Modification Point:
Modify uint8_t xmodem_rx_frame(uint8_t* p_xmodem_buff) to determine the end frame, responding to two EOTs with NACK and ACK respectively.
05
Verification Mechanism Upgrade
X Modem Verification:
Uses checksum or CRC16; currently, the X Modem example uses checksum.
Y Modem Verification:
Y Modem mandates the use of CRC16 verification, with the calculation scope clearly defined as the information block data (excluding frame headers, packet numbers, etc.). Ensure that the CRC16 calculation function is accurate, modifying the simple verification logic that may exist in the original X Modem:
Modification Point:
Add a function static uint16_t CRC16_check(unsigned char *q, int len) to perform CRC16 verification on the data.
Remove the X Modem checksum logic, enforcing the use of CRC16 verification.
06
Data Buffer Configuration
X Modem Data Buffer Configuration:
XModem data packets are sent to a buffer controlled by buffer.c. This buffer is a circular buffer, meaning that when it reaches the end, it wraps back to the start. Since the data frame reception array has changed from 132 bytes to 1029 bytes, RAM overhead has increased.
In the XModem example, each packet is 132 bytes (128 data + 3 header + 1 checksum), and the code defines XMODEM_FRAME_SIZE as 132U.
Y Modem Data Buffer Configuration:
In the YModem example, YMODEM_FRAME_SIZE_1024 is defined as 1029U, and YMODEM_FRAME_SIZE_128 as 133U.
Define the circular storage BUFFER_SIZE as 1542 to maintain the original configuration, ensuring normal data parsing.
Modification Point:
Increase BUFFER_SIZE based on actual test results.
07
Hardware Driver and Configuration Adaptation
The Renesas RX series must ensure that the serial port driver is adapted to the baud rate, data bits, stop bits, and other configurations of Y Modem. The smart configurator can be used for driver configuration (e.g., common baud rate 115200bps, 8 data bits, 1 stop bit, no parity, etc.).
08
Multi-File Transfer Adaptation
If the OTA needs to transfer multiple files, logic for traversing multiple files and constructing initial frames + data frames + end frames one by one must be added to the code. Since the customer only requires the transfer of a single file, no related modifications are involved.
3
Test Results
01
Test Environment Setup
Click to view the full image
02
Functional Testing
-
The MCU executes the bootloader upgrade program, and the serial output shows “Please start file send using YModem protocol…”;
-
Teraterm selects the Y Modem protocol to send the firmware file;
-
During transmission, the frame sequence is captured using Bus Hound to verify:
-
Initial frame (filename/size correct);
-
Data frame (1024-byte blocks and CRC16 verification correct);
-
End frame (determination correct).
-
After the upgrade is complete, the MCU automatically jumps to the new firmware, and functional verification passes.
Need Technical Support?
If you have any issues using Renesas MCU/MPU products, you can scan the QR code below or copy the URL into your browser to access the Renesas Technical Forum for answers or online technical support.
https://community-ja.renesas.com/zh/forums-groups/mcu-mpu/
1
END
1
Recommended Reading
Introduction to Renesas RX Motor Control Solutions
Introduction to RX13T Fan Drive Solutions
Debugger Giveaway | Live: Renesas RX13T Fan Solution
