組込ソフトの開発現場では、モトローラSレコードを直接見たり、少し加工したりすることもしばしばです。その都度、,ネットをみたり、昔作ったツールのコードを見たり手間なので自分用に必要なことだけをまとめておきます。
レコードの種類
レコードレイアウトはより、まずレコードの種類で悩みます。
| 種類 | 項目名 | 説明 |
| S0 | コメント | ROM書き用なら削除してよい。 コンパイラが吐いたものなら削除していい。 生産情報ょ埋込むユーザさんもいるのでたくさんある場合は注意。 |
| S1 | 16bitアドレスデータ | S2、S3と混在もOK。並びは基本アドレスの昇順。 |
| S2 | 24bitアドレスデータ | S1、S3と混在もOK。並びは基本アドレスの昇順。 |
| S3 | 32bitアドレスデータ | S1、S2と混在もOK。並びは基本アドレスの昇順。 |
| S4 | リサーブ | |
| S5 | 16bitアドレスデータレコード数 | ほとんど見たことがない。 ROM読書き時は無視してもよい。 |
| S6 | 24bitアドレスデータレコード数 | ほとんど見たことがない。 ROM読書き時は無視してもよい。 |
| S7 | S3セグメントの末尾に付与される。 | ここのデータ数値は諸説あるようだが、ROM読書きでは使用しない。 チェックサムではない。 次セグメントのアドレスoffsetは、Intel Hexの方である。 |
| S8 | S2セグメントの末尾に付与される。 | ここのデータ数値は諸説あるようだが、ROM読書きでは使用しない。 チェックサムではない。 次セグメントのアドレスoffsetは、Intel Hexの方である。 |
| S9 | S1セグメントの末尾に付与される。 | ここのデータ数値は諸説あるようだが、ROM読書きでは使用しない。 チェックサムではない。 次セグメントのアドレスoffsetは、Intel Hexの方である。 |
| その他 | 全体のチェックサム行はない。 |
レコードのフォーマット
まず vim の .mot 設定をSetupしましょう。詳しくはこちら。
S1レコード:
| byte位置 1基点 | 桁数 | 内容 |
| 1 | 2 | レコードタイプ |
| 3 | 2 | レコード長、16進、 データ長 ÷2 + 8 |
| 4 | 8 | アドレス、16進 |
| 13桁以降 | 2～512 | データ、16進、データ長は最大255 |
| 後ろから | 2 | チェックサム, 0xFF – アドレス以降の2桁毎のバイナリ値の総和を256で割った余り |
S2レコード:
| byte位置 1基点 | 桁数 | 内容 |
| 1 | 2 | レコードタイプ |
| 3 | 2 | レコード長、16進、 データ長÷2 + 12 |
| 4 | 12 | アドレス、16進 |
| 17桁以降 | 2～512 | データ、16進、データ長は最大255 |
| 後ろから | 2 | チェックサム、上に同じ |
S3レコード:
| byte位置 1基点 | 桁数 | 内容 |
| 1 | 2 | レコードタイプ |
| 3 | 2 | レコード長、16進、 データ長桁数÷2 + 16 |
| 4 | 16 | アドレス、16進 |
| 21桁以降 | 2～512 | データ、16進、データ長は最大255 |
| 後ろから | 2 | チェックサム、上に同じ |
注意点
読込み時は、
- コンパイラによって、マイコンのアドレス範囲によって、S1、S2、S3 がごちゃ混ぜになる場合がある。(コンパイラ次第ではレコード種を指定すれば回避化可能)
- コンパイラによって、レコードデータ長が統一されない場合がある。
- コンパイラによって、ブランクが空く場合がある。(コンパイラ次第では出力アドレス範囲を指定すれば回避可能)
自ら生成する場合は、
- 利用先システムよって、レコードデータ長が統一されないと異常動作する場合がある。
- 利用先システムよって、ブランクあると異常動作する場合がある。
- 利用先システムよって、データフラッシュやRAM領域など、アドレスが 0xFxxx xxxx で書かれたデータを読むと落ちる場合がある。(絶対アドレスとしてメモリ確保されてしまうと当然足りない…)
弊方では、モトローラSレコード、Intel Hex fileのROMデータ加工アプリケーションとAPIライブラリも開発しております。自社で作るのは面倒、時間がない、土台となるコードがないなどありましたら、こちらより気軽にご相談ください。