初めて投稿させていただきます もぐら と申します。
よろしくお願い致します。
RL78G13マイコンをE2シミュレータLiteを使用してCS+でデバッグを行っております。
CS+にてメモリ表示機能([表示]->[メモリ])を使ってコード・フラッシュメモリを確認してみたところ、
ベクタテーブルの0x00000番地がダウンロードしたmotファイルと異なるデータとなっておりました。
■ダウンロードしたmotファイルのデータ
S1130000D800FFFF00000000000000000000000016
■CS+からメモリ表示機能を使用した時に表示されたデータ
00000 | D0 00 FF FF 00 00 00 00 00 00 00 00 00 00 00 00
また、プログラムで0x00000番地を直接リードしてみましたが、こちらもメモリ表示機能と同じく”0xD0”が取得されました。
そこで質問させていただきたいのですが、RL78G13マイコンのコード・フラッシュメモリはCS+からのメモリダンプや
プログラムからのリードでは確認することが出来ないのでしょうか？
また、リードするための設定や手順などありましたら教えていただけると幸いです。
チョコです。
これは、デバッガがデバッグするために、リセットベクタの値を書き換えることで、リセットでデバッガを起動しているからです。
E2Liteのようなエミュレータを使用する場合にはメモリの一部をデバッガが使うことで、OCDでのデバッグが可能になります。
D8H番地以降がユーザのプログラムです。それより前はオプションバイトや割り込みベクタテーブル等なので、通常はあまり気にする必要はありません。
デバッガをE2Liteからシミュレータにすれば、motファイルの値と同じになるはずです。
情報を追加しておきます。
プロジェクト（ここではG13_INTP10の場合の例です）をビルドすると、DefaultBuildディレクトリに以下のようなファイルが生成されます。
ここのG13_INTP10.mapがマップファイルでプロジェクトのマップ情報が入っています。
その中のコードフラッシュの部分は以下のようになっています。
0～7fの部分が.vectで、リセットと割り込みのベクタテーブル用の領域です。この部分の詳細はハードウェアマニュアルの第3章「CPUアーキテクチャ」の「メモリ空間」や第16章「割り込み機能」の章を参照してください。
ce～d7番地の.monitor1がデバッガ用のリセットエントリ処理部分です。D8番地はプログラム用のリセットエントリでスタートアップルーチンがここから始まります。デバッグ時には、このスタートアップルーチンの代わりに、デバッガを起動させるために0番地と1番地が書き換わっています。下のプロジェクトツリーで反転表示になっているcstart.asmがスタートアップルーチンです。
d8番地からの.textがプログラムが配置される領域です。
最後の.monitor2がブレークポイント（ソフトウェアブレークポイント）をプログラム中に埋め込むための処理を行っている処理部です。この領域はコードフラッシュの最後の512バイトになります。
と言うことで、プログラムをOCD機能を使ってデバッグできるようにするための仕組みが問題の部分です。
これは、そんなものと思ってください。