Motorola S-Record Format

After changing old project software, I experienced problems while reading
the S-record file for flash programming. The previously used tool was a
very old DOS program no more available today. Fortunately, I now have a
self written tool in use what allows to examine the reason. 

The suspicious section is at the file end, where the 16 bit start vector is
at last address of 64 k space (0xffff). The linker control file has a INIT
statement and linker with old DOS Programmer puts the adress of label
behind the INIT statement automatically at address 0xffff. Therefore the
last line of S-record looks like:

S9 03 1003 E9

S9 indicates last line of S-Record
03 indicates 3 data bytes in line
1003 is the start vector adress (what will be stored at location 0xffff)
E9 is the checksum

My flasher complains, becouse destination adress 0xffff is missing and he
does not know about the correct destination for the start vector in memory.
If I use own segment instead of INIT instruction, the start vector appears
in the line before last s-record line with correct adress and everything is
fine. The last line then looks like S0 03 FFFF FE what will be rejected by
my flasher. What is the meaning of S9 ? Is this incompability a bug of my
programmer or a bug of the linker or simply undocumented feature ?

Hi J=FCrgen,

J=FCrgen Veith wrote:
[ lots of assumptions about Motorola-S-Format]

I have never seen an S9 record used for something else than
for the "end record".
It seems your programming tool does not know where to put the
start vector.
Why don't you put something like

	org	0xfffe
	db	start_vec

into your source code (assuming assembler)?
Then there will be a S1 record with a start address
of FFFE and the start vector in it.

HTH
Wolfgang

--=20
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at

ok solved - the problem was not the S9 but the S0 line.
The S0 line contains some unknown things like Compiler Version, comments and
the module name. That line was longer than the maximum 32 bytes of my
buffer and therefore the program stopped with error message. I increased
max line length to 64 and everything is fine now.

Nevertheless, it would be nice, if anybody knows what secret codes the
diffrent compilers store inside the S0 line. Probably I am going to display
this infos in my flasher window while flashing. 

"J&uuml;rgen Veith" <janvi@t-online.de> wrote in message
news:43e783b1$0$350$9b4e6d93@newsread2.arcor-online.net...
> ok solved - the problem was not the S9 but the S0 line.
> The S0 line contains some unknown things like Compiler Version, comments
and
> the module name. That line was longer than the maximum 32 bytes of my
> buffer and therefore the program stopped with error message. I increased
> max line length to 64 and everything is fine now.
>
> Nevertheless, it would be nice, if anybody knows what secret codes the
> diffrent compilers store inside the S0 line. Probably I am going to
display
> this infos in my flasher window while flashing.

Ok, crash course in self-help:

1. Open your internet browser
2. enter www.google.com in the address bar.
3. type "motorola s record" on the Google page
4. click on the first link google found for you (16.600 hits found)
5. start reading

Meindert

Meindert Sprang wrote:
> "J=FCrgen Veith" <janvi@t-online.de> wrote in message
> news:43e783b1$0$350$9b4e6d93@newsread2.arcor-online.net...
> > ok solved - the problem was not the S9 but the S0 line.
> > The S0 line contains some unknown things like Compiler Version, comments
> and
> > the module name. That line was longer than the maximum 32 bytes of my
> > buffer and therefore the program stopped with error message. I increased
> > max line length to 64 and everything is fine now.
> >
> > Nevertheless, it would be nice, if anybody knows what secret codes the
> > diffrent compilers store inside the S0 line. Probably I am going to
> display
> > this infos in my flasher window while flashing.
>
> Ok, crash course in self-help:
>
> 1. Open your internet browser
> 2. enter www.google.com in the address bar.
> 3. type "motorola s record" on the Google page
> 4. click on the first link google found for you (16.600 hits found)
> 5. start reading

Crash course in providing useful advice...

if it ain't useful, keep it to yourself!

I have been through this process and there are lots of *poor*
references on s-records.  I had to read a bunch of them to put together
a complete (and hopefully accurate) description of s-records.  Even
then I was not sure it would work for all situations as there seems to
be a lot of variability in how s-records are used.

You don't need to be rude.  That only makes you look stupid.

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:1139253940.507577.232300@z14g2000cwz.googlegroups.com...
Meindert Sprang wrote:
>> Ok, crash course in self-help:
>>
>> 1. Open your internet browser
>> 2. enter www.google.com in the address bar.
>> 3. type "motorola s record" on the Google page
>> 4. click on the first link google found for you (16.600 hits found)
>> 5. start reading

> Crash course in providing useful advice...
>
> if it ain't useful, keep it to yourself!

Believe me, if I advise to search on google, I have *always* checked first
if the search phrase returned any useful info. And the first link does give
a fairly complete description of the format.

> I have been through this process and there are lots of *poor*
> references on s-records.  I had to read a bunch of them to put together
> a complete (and hopefully accurate) description of s-records.  Even
> then I was not sure it would work for all situations as there seems to
> be a lot of variability in how s-records are used.

> You don't need to be rude.  That only makes you look stupid.

Wasn't meant to be rude. I thougth I was pointing out the obvious....

Meindert

Meindert Sprang wrote:
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> > if it ain't useful, keep it to yourself!
>
> Believe me, if I advise to search on google, I have *always* checked first
> if the search phrase returned any useful info. And the first link does give
> a fairly complete description of the format.
>
> > I have been through this process and there are lots of *poor*
> > references on s-records.  I had to read a bunch of them to put together
> > a complete (and hopefully accurate) description of s-records.  Even
> > then I was not sure it would work for all situations as there seems to
> > be a lot of variability in how s-records are used.
>
> > You don't need to be rude.  That only makes you look stupid.
>
> Wasn't meant to be rude. I thougth I was pointing out the obvious....

It was not obvious or even accurate.  The answer to the OP's question
was not on the first link or likely any of the links.  He was asking
what the tools put into the S0 record.  If you read the link it says
that the S0 record contains among other things...

description is char[0-36] and is a text comment

The OP was asking what the tools put into this comment field.   That is
outside of the S record spec other than the 36 char max length.

So do you have any information that is *useful* to the OP?

"rickman" <spamgoeshere4@yahoo.com> writes:
> Meindert Sprang wrote:
> > "rickman" <spamgoeshere4@yahoo.com> wrote

> > > if it ain't useful, keep it to yourself!
> >
> > Believe me, if I advise to search on google, I have *always* checked first
> > if the search phrase returned any useful info. And the first link does give
> > a fairly complete description of the format.
> >
> > > I have been through this process and there are lots of *poor*
> > > references on s-records.  I had to read a bunch of them to put together
> > > a complete (and hopefully accurate) description of s-records.  Even
> > > then I was not sure it would work for all situations as there seems to
> > > be a lot of variability in how s-records are used.
> >
> > > You don't need to be rude.  That only makes you look stupid.
> >
> > Wasn't meant to be rude. I thougth I was pointing out the obvious....
> 
> It was not obvious or even accurate.  The answer to the OP's question
> was not on the first link or likely any of the links.  He was asking
> what the tools put into the S0 record.  If you read the link it says
> that the S0 record contains among other things...
> 
> description is char[0-36] and is a text comment

Where did you find a supposed 36-character limit specified?

The format allows up to 99 characters and S-recs date back
to (late) punchcard days, so being prepared for up to 80
characters would be wise.

> The OP was asking what the tools put into this comment field.   That is
> outside of the S record spec other than the 36 char max length.
> 
> So do you have any information that is *useful* to the OP?

Everett M. Greene wrote:
> "rickman" <spamgoeshere4@yahoo.com> writes:
> > It was not obvious or even accurate.  The answer to the OP's question
> > was not on the first link or likely any of the links.  He was asking
> > what the tools put into the S0 record.  If you read the link it says
> > that the S0 record contains among other things...
> >
> > description is char[0-36] and is a text comment
>
> Where did you find a supposed 36-character limit specified?

http://www.amelek.gda.pl/avr/uisp/srecord.htm

go to the description for the S0 record type...

S0 Record. The type of record is 'S0' (0x5330). The address field is
unused and will be filled with zeros (0x0000). The header information
within the data field is divided into the following subfields.

mname is char[20] and is the module name.
ver is char[2] and is the version number.
rev is char[2] and is the revision number.
description is char[0-36] and is a text comment.

36 is for just the text comment, but this may be the ascii which is
represented by two char in the Srecord for a total of 72 char.  But
that was my point.  There is a lot of info on the Srecord format, but
much of it is incomplete and/or misleading.  I don't think much of
being rude or even just negative in the forums.  This was an example
that was completely unjustified.


> The format allows up to 99 characters and S-recs date back
> to (late) punchcard days, so being prepared for up to 80
> characters would be wise.

Do you have a reference that describes this?  I have never found a
complete, definitive description of Srecords.

there are a few things:

1) some linkers put the start vector into the S9 line without explicit
instruction to do so

2) some flash programmers read the S9 line and flash the vector to the CPU
specific destination address without explicit instruction to do so

3) some programmers (like I did in my old project) use the 1+2 features and
do not now about. I am not going to implement that feature in my flasher
becouse it seems better to force programmers for explicit link of own
vector section with reset and other vectors

4) even if the project is assembly without any HLL library, customers can
possibly find out the tools used in the project by analyzing the S0 line.