1. Home
  2. Embedded Programming
  3. Motorola S-Record Format

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 ?

Reply to
Jürgen Veith
Loading thread data ...

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

Reply to
Wolfgang Mahringer

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.

Reply to
Jürgen Veith

and

display

Ok, crash course in self-help:

  1. Open your internet browser
  2. enter
    formatting link
    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

Reply to
Meindert Sprang

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.

Reply to
rickman

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.

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

Meindert

Reply to
Meindert Sprang

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?

Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.