Richard wrote:
> "Clifford Heath" <no@spam.please.net> wrote in message
>> CBFalconer wrote:
>
>>> Sounds as if the above is an absolute address format, with no
>>> checking whatsoever.
>>
>> That was my guess.
>>
>>> Then the next question is "what is ihex
>>> format". After which the conversion sounds trivial.
>>
>> If that means Intel Hex format, and msp430-jtag handles it, then
>> I can do the rest.
>
> I think Intel Hex is default of msp430-jtag.
>
> "msp430-jtag --help" for details.
>
> ihex is objcopy speak for Intel Hex.
The following exercpt from ppmanual (available in full at the URL
in my sig below) may be useful. It is presented as a quotation to
avoid line wrap at transmission, although the receiver may do funny
things to it.
> The structure of RBM files is best explained by first explaining HEX
> files.
>
> A HEX file is made up entirely of printing characters, and can be
> tranmitted and manipulated as a text file. A record, in a HEX file,
> begins with the ":" character, has several fields containing only
> the hexadecimal characters '0' through '9' and 'A' through 'F'. The
> fields are as follows:
>
>
> colon The character ":", beginning a record.
>
> length 2 hex characters, describing a value in the range
> 0 to 255 only. This value specifies the length
> of the remainder of the record.
>
> address 4 hex characters, describing an address in the
> range 0 to 65535 (under some circumstances this
> is considered a signed integer in the range -
> 32768 to 32767).
>
> type 2 hex characters, describing a value in the range
> 0 to 255 only. The interpretation of this value
> is central to the use of RBM files.
>
> data (2 times length) hex characters. Interpretation
> varies with use.
>
> checksum 2 hex characters, such that when each character
> pair since the ":" is considered as a number in
> the range (0..255), the sum MODULO 256 will be
> zero.
>
> anything except a ":" may follow the checksum, and may be
> used for formatting, comments, etc. It is always
> ignored.
>
> Note that every data item, after the initial colon, can be expressed
> as a one byte value, thus reducing storage requirements,
> transmission time, etc. by at least a factor of 2.
>
> The original INTEL standard defined record types 0 and 1. Type 0 is
> an absolute load code record, in which "address" describes the
> machine address to be loaded with the first byte in the data field.
> Type 1 is an end-of-file record, with length always zero, and
> address describing an address to which execution control is to be
> transferred. Type 0, when length is zero, is treated in the same
> manner. By convention, a transfer address of zero in these
> end-of-file records signifies that no control transfer is to be
> made.
>
>
> 12.2 RBM files
>
> RBM records are exact images of HEX records, except that the leading
> colon and trailing checksum have been discarded, and that the
> information is presented as 8 bit bytes in place of pairs of
> hexadecimal characters. No trailing "anything" field is permitted,
> and a new record begins immediately after the previous record ends.
> Verification of storage is left up to the storage system on which
> the files reside (typically CRC checksums over the storage blocks).
> Thus RBM records can be discussed in exactly the same terms as HEX
> records, and conversion between the systems is easy.
>
>
> 12.2.1 RBM record types
>
> To preserve compatibility RBM files retain the original INTEL
> definitions of record types 0 and 1, and add further types starting
> at type 128 (080 hex). In all cases the length byte describes the
> number of bytes in the data field, which may be zero. Additional
> types are:
>
> 128 Relocatable data record. Exactly analogous to
> the absolute data record (0), but the address
> field describes the location with respect to the
> base of the current module.
>
> 129 End module record. Address and length are zero.
>
> 130 Relocatable Code Module Header. The relocatable
> records which follow are to be placed in a code
> segment. The address field describes the total
> length of the following code. The data field,
> (which may be empty) may hold a name for the
> segment of up to 60 characters.
>
> 131 Entrypoint descriptor. Address is a value
> relative to the base of the current segment.
> Data holds the name of the entrypoint, in Ascii
> characters.
>
> 132 Absolute entry. Address is an absolute value,
> which is to be used to resolve any referances to
> the name in the data field (again in Ascii
> characters).
>
> 133 External referance. Address is an index value
> used by the linkage records which follow. The
> data field holds a name, in Ascii, whose actual
> value is described in some other module. Note
> that the index in the address field will never be
> less than 2, because indices 0 and 1 are reserved
> to describe code and data module relative
> relocation.
>
> 134 Data module header. As type 130, except that the
> following data records are to be placed in the
> data segment.
>
> 135 Alignment Record. Must only occur immediately
> after a module header record. Causes the module
> to adjust its location so that the absolute
> location, modulo the address field, is zero. The
> data field is unused.
>
> 136 Pcd module entry point. At linkage time this
> value must have the high order 8 bits set to the
> module number in which it occured, in the range 1
> to 127 (only 31 at present). The data field
> contains the entry name. These records are used
> to describe PCD linkages in terms of
> segment/entrynumber pairs. The occurance of such
> an entry point causes LINKER to assume that the
> output is to be a PCD program.
>
> 137 Equate names. Not presently implemented.
> Address field is unused. The data field contains
> two Ascii names separated by the "=" character,
> as in "name1=name2". Causes all referances to
> name1 to be resolved as referances to name2. The
> data field should not exceed 60 characters, thus
> effectively limiting names to less than 30
> characters.
>
> 138
>
> thru Reserved, not presently assigned.
>
> 143
>
> Types 144 through 159 are reserved as linkage records, in which the
> type modulo 16 is used as an operator. The address field (except
> for types 152 through 154 below) contains an index, which refers to
> an external referance record active within this module (or 0 or 1 to
> specify the current code or data segment bases), and the data field
> contains a list of 16 bit addresses, in high byte first format,
> specifying a location relative to the current module beginning which
> is to be adjusted. All operators discard any carrys and borrows,
> and thus never cause arithmetic overflows. The operators currently
> assigned are:
>
>
> 144 Add lobytefirst words. The value of external
> referance is added to the two bytes of the
> module.
>
> 145 Subtract lobytefirst. The value of external
> referance is subtracted from the two bytes of the
> module.
>
> 146 Add byte. The value of external referance, low
> order 8 bits only, is added to the byte of the
> module.
>
> 147 Subtract byte. The value of external referance,
> low order 8 bits only, is subtracted from the
> byte of the module.
>
> 148 Add high byte. The value of external referance,
> high order 8 bits only, is added to the byte of
> the module.
>
> 149 Subtract high byte. The value of external
> referance, high order 8 bits, is subtracted from
> the byte of the module.
>
> 150 Add hibytefirst words. Similar to type 144, but
> the module contents is treated as a high byte
> first integer. Note that this does not affect
> the value of the external.
>
> 151 Subtract hibytefirst words. As 150, but external
> referance is subtracted from the module content.
>
> Types 152 through 154 are anonymous linkage records. Address
> contains the value of the "external", rather than an index to it's
> entry record. These records permit construction of one pass
> assemblers and codegenerators, by postponing "fixup" operations to
> linkage time. Since modules are in their most compact form at
> linkage time, and since general code generation always requires a
> two pass algorithm at some point, the linkage step is the most
> efficient point at which to implement the second pass.
>
>
> 152 Add lowbytefirst fixup linkage.
>
> 153 Add hibytefirst fixup linkage.
>
> 154 Add byte (8 bits only) fixup linkage.
>
>
> 155
>
> thru Unassigned operators.
>
> 159
>
>
> 160
>
> thru Reserved for future use.
>
> 191
>
>
> 192 up Available for system dependant special operations
> which cannot be handled by the existing types.
> No reliance on portablity should be made when
> these types are used.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!