ADuCM360 + AN-1160 + CM3WSD + downloading sample.hex file

The utility application CM3WSD includes a "sample.hex" file. That file is fairly straight-forward until one gets to:

:04000005000001E90D

The Intel hex record format defines a record type of 05 as:

Start Linear Address Record. The address field is 0000, the byte count is 04. The 4 data bytes represent the 32-bit value loaded into the EIP register of the 80386 and higher CPU. --Wikipedia

Obviously, the ARM Cortex-M3 doesn't have an EIP register.

Questions that come to mind:

What is expected by this record?

How should it be processed?

What does the CM3WSD application do with it?

When CM3WSD pushes data over the serial port, using the sample.hex as input to the application, during "Program," I see the checksum field of the message as FFFFFFB4, which is not within the range specified by AN-1160, which says that the checksum range is 0x00 to 0xFF. I have not yet independently verified this finding, except in terms of my initial testing, which is based on an application that reads byte-by-byte anything that comes over the serial port. It also writes an ACK after each message so that the CM3WSD side "keeps going."

Is anyone else able to verify that the data being sent by CM3WSD is in-fact not simply two bytes, one for each nibble of the unsigned character value of the checksum?

The AN-1160 document suggests that from "using a port analyzer" that the checksum is a two serial bytes that represent one byte in hexadecimal form.

My code reads a single byte at a time from the serial port of one PC connected to the serial port of another PC running the CM3WSD application. During a "Mass Erase" command, the expected bytes arrive in sequence as follows:

07 0E 06 45 00 00 00 00 00 FFFFFFB5

This is contrary to the AN-1160 command examples that show only the two characters representing the single byte checksum and not all of the leading Fs. Is someone able to independently verify my findings? I have tested similar code on both Linux and Windows and am seeing the same results: The checksum is being sent as 8 hex characters and not 2 as indicated in AN-1160.

I've noticed that the CM3WSD application sends the W command out with a maximum of 10h (real) data bytes as payload. Do we know if it will ever send any more "write data" bytes in a W command? The protocol allows for a maximum of 250 bytes of what I'm calling "real data" bytes. I don't want to waste storage on buffers that are never used.

I'm guessing that the CM3WSD application parses the iHex records and then chunks them into W commands 10h bytes at a time unless there is a short write, which then it sends what is left.

Do we know if we should plan buffer sizes to match the data sizes used by CM3WSD or if we can safely scale down to meet just the observed length of data in a W command?