It may be that there are relatively few people using this function, or the length of the transmitted data is less than 128byte * 255 byte, so the triggering conditions for the above problems are not encountered;
I actually discovered this problem during testing. Continuous transmission always fails at block 255.
The following is the protocol's definition of blk cblk, cblk = 255 - blk The original content of the agreement (https://www.menie.org/georges/embedded/xmodem_specification.html) is as follows: -------- 3. MESSAGE BLOCK LEVEL PROTOCOL Each block of the transfer looks like: <SOH><blk #><255-blk #><--128 data bytes--><cksum> in which: <SOH> = 01 hex <blk #> = binary number, starts at 01 increments by 1, and wraps 0FFH to 00H (not to 01) <255-blk #> = blk # after going thru 8080 "CMA" instr, i.e. each bit complemented in the 8-bit block number. Formally, this is the "ones complement".
<cksum> = the sum of the data bytes only. Toss any carry.
在 2024/2/5 22:25, Dan Carpenter 写道:
On Mon, Feb 05, 2024 at 02:58:50PM +0800, Hongbin Ji wrote:
When the blk sequence number is 255 and cblk is 0, the original XOR condition produces a result of 0,and the judgment condition will be unsuccessful.
This code is 18 years old so it's surprising that it's causing an issue now. This was added in commit f2841d377060 ("Add support for ymodem protocol (loady command). Patch by Stefano Babic, 29 Mar 2006").
Not just 255 and zero but any time "blk == 255 - cblk" then your new condition will be true where the original condition was false. Is that really intentional? Is this from reviewing documentation or something? What documents? Or is it from testing?
regards, dan carpenter