This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FW: Re: Why is my executabel in DOS file format?






We can all post specs:
    http://home.socal.rr.com/awi/srecords.htm

grrrr.... ;-) I'm talking about the REAL spec written by Motorola, not what some guy wrote on his webpage.


I looked and noticed it says "...Each record MAY be terminated with a CR/LF/NULL...."*
MAY MAY MAY.
Also note when they define an Srecord (which is one line in the file) they DO NOT include cr/lf... (any line termination) they just give:
"The 5 fields which comprise an S-record are:
TYPE RECORD LENGTH ADDRESS CODE/DATA CHECKSUM"



ANYWAYS - moving on. I LOVE the idea of putting in a command argument for how the srecord will be terminated. Keep me posted what comes about with that.


Here is what I did :
1. I tried the suggested change to srec.c and yes it works great - I don't have to run dos2unix now.
2. Then, I used a hex editor to see what EOL characters were in the files.
- After running DOS2UNIX there is at the end of a line : 0x0a that's it.
- The file that is currently generated by the srec.c code has: 0x0d 0x0a .
- The file that is created by the srec.c mod \n has : 0x0a.


Now, the problem I think is that when I go to program my microcontroller or flash with the s19 file linux chokes on the 0x0d 0x0a ending because as a UNIX / LINUX environment (as was pointed out) it is expecting just 0x0a with means NEWLINE (cr/lf functionality to unix). So basically /n = 0x0a linux, and for dos /n=0x0d 0x0a.

Now one more thing to note. When I use Windows/DOS there is NO problem using EITHER file.
The s19 created by LINUX with 0x0a endings, or with 0x0d,0x0a line endings BOTH work fine in a dos environment.


Michael B

*
----------------------------------------------------------------------------------------------------------------
S-RECORD INFORMATION
E.1 INTRODUCTION

The S-record output format encodes program and data object modules
into a printable (ASCII) format. This allows viewing of the object
file with standard tools and allows display of the module while
transferring from one computer to the next or during loads between a
host and target. The S-record format also includes information for
use in error checking to insure the integrity of data transfers.

E.2 S-RECORD CONTENT

S-Records are character strings made of several fields which identify
the record type, record length, memory address, code/data, and
checksum. Each byte of binary data is encoded as a 2-character
hexadecimal number: the first character representing the high-order
4 bits, and the second the low-order 4 bits of the byte.

The 5 fields which comprise an S-record are:
TYPE RECORD LENGTH ADDRESS CODE/DATA CHECKSUM

The fields are defined as follows:
FIELD CHARACTERS CONTENTS
----- ---------- --------
Type 2 S-record type - S1, S9, etc.
Record 2 The count of the character pairs in the
length record, excluding the type and record
length.
Address 4, 6, The 2-, 3-, or 4-byte address at which
or 8 the data field is to be loaded into
memory.
Code/data 0-2n From 0 to n bytes of executable code,
memory loadable data, or descriptive
information.
Checksum 2 The least significant byte of the one?s
complement of the sum of the values
represented by the pairs of characters
making up the record length, address,
and the code/data fields.

Each record may be terminated with a CR/LF/NULL.

E.3 S-RECORD TYPES

Eight types of s-records have been defined to accommodate various
encoding, transportation, and decoding needs. The Freeware
assemblers use only two types, the S1 and S9:
S1 A record containing code/data and the 2-byte
address at which the code/data is to reside.
S9 A termination record for a block of S1 records. The address
field may optionally contain the 2-byte address of the
instruction to which control is to be passed. If not
specified, the first entry point specifica
tion encountered in the object module input will be used.
There is no code/data field.

E.4 S-RECORD EXAMPLE

The following is a typical S-record module:
S1130000285F245F2212226A000424290008237C2A
S11300100002000800082629001853812341001813
S113002041E900084E42234300182342000824A952
S107003000144ED492
S9030000FC
The module consists of four code/data records and an S9 termination
record.
The first S1 code/data record is explained as follows:
S1 S-record type S1, indicating a code/data record to be
loaded/verified at a 2-byte address.
13 Hex 13 (decimal 19), indicating 19 character pairs,
representing 19 bytes of binary data, follow.
00 Four-character 2-byte address field: hex address 0000,
indicates location where the following data is to be loaded.
The next 16 character pairs are the ASCII bytes of the actual
program code/data
2A Checksum of the first S1 record.
The second and third S1 code/data records each also contain $13
character pairs and are ended with checksums. The fourth S1 code/data
record contains 7 character pairs.
The S9 termination record is explained as follows:
S9 S-record type S9, indicating a termination record.
03 Hex 03, indicating three character pairs (3 bytes) to
follow.
00 Four character 2-byte address field, zeroes.
00
FC Checksum of S9 record.

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]