How to determine the length of the last data field in a SDO block transfer?
TL;DR: The bits aren't set in the last segment of a sub-block. They are set in a separate message that follows the last sub-block.



Unfortunately, the answer is a little bit more complicated. CiA 301 defines a SDO block download in three phases, see 7.2.4.3.8:


SDO block download initiation (7.2.4.3.9)
SDO block download sub-block (7.2.4.3.10)
SDO block download end  (7.2.4.3.11)


As per 7.2.4.3.10, a block download ends when the MSB of the frame is set to 1 (called c in the documentation). That's where you apply 0x80. Your log and logic seems to follow the specification so far.

However, there are no bits to set for the length. At least not in that frame. Instead, the server's acknowledgement must be followed by another frame that contains the following data:

(1) (2) X C | CRC               | Reserved
110 NNN 0 1 | CCCCCCCC CCCCCCCC | 00000000 00000000 00000000 00000000 00000000
0             1        2          3        4        5        6        7        (Byte)


Here, (1) is the client command specifier and should be 6, due to the block download. C is the client subcommand and should be 1 (otherwise you would initiate another block download). X is not used and should be 0.

The important bits are now NNN, which indicate the number of bytes that didn't contain any data in the last segment of the last block. As your last block only contained a single byte, NNN should be 110 (bytes [8-6,7]=[2,7] didn't contain valid data).

So in your notation, the end of the block transfer should look like this:

TX:  "     618   [8]  DE 0A 00 00 00 00 00 00" // your last message
RX:  "     598   [8]  A2 5E 00 00 00 00 00 00" // Server ACK of block transfer
TX:  "     618   [8]  DD ?? ?? 00 00 00 00 00" // Block End, 0xdd = 0xc1 + (n &lt;&lt; 2)
RX:  "     598   [8]  A1 00 00 00 00 00 00 00" // Server ACK of block end


?? indicate CRC bytes that depend on the transfer. Apparently, both sides of your CANopen implementation did not conform to the protocl as defined in 7.2.4.3.8 and ignored the missing download end; you should probably check both sides whether they follow CiA 301 in that regard.