AnsweredAssumed Answered

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

Question asked by rw_ on Jul 2, 2013
Latest reply on Jul 17, 2013 by rw_

  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.

 

Regards,

 

rw_

Outcomes