XModem and Padding Bytes

The GHI Firmware Update tool likely uses XModem-1K for file transfers (I think).

I wonder, how are the padding bytes handled? Since XModem uses the character (ASCII 26) for padding in order to fill up a packet, wouldn’t this distort the file length?

For example, let’s say I’m transferring a file that’s originally 1,028 bytes long. The 1st packet will contain 1,024 data bytes, followed by the 2nd packet which will only have 4 data bytes padded with 1,020 characters to fill up the required packet length. Suddenly, on the receiving side, I’m going to end up with 2,048 bytes. How does FEZ know what the original file length is? And what does it do with the padding bytes?

On the surface, you might say, “Oh, if you see a bunch of characters at the end, then it’s padding and it can simply be discarded.” But what if your binary file (firmware file) legitimately does have several characters at the end that really are supposed to be there? How would the receiver know which ones to discard?

Or does FEZ have some other clever way of handling this? . . . . Maybe a character is never supposed to show up in a deployment file? Or maybe a firmware file is always a fixed multiple of 1,024 bytes, so that padding is never an issue?

[Update] Since .HEX files are basically text files, the byte should never show up. What about .SIG files, which are binary? Are they actually transmitted to the FEZ or are they simply used locally?

This is a trade secret :wink:

Just kidding! The firmware is always 1024 byte multiple. There is no padding :slight_smile:

Awesome! Thanks, Gus.

Out of curiosity, what do the *.sig files do?

You can put a Signature Key on your NETMF Device. It then only accepts hex files, which are also signed with the same key. The .sig file contains the signature for the hex file.
You can use MFDeploy to generate keys, sign hex files, and write a key to your device.
But be aware! If you write a key to your device, anmd you loose it, then the device might be unusable.

Thanks, that’s good to know. And whatever is reading the sig inside the FEZ probably only reads the first 128 bytes and discards the rest, thus avoiding the extraneous padding.