CS+のメモリ表示についての質問

チョコです。

これは、デバッガがデバッグするために、リセットベクタの値を書き換えることで、リセットでデバッガを起動しているからです。

E2Liteのようなエミュレータを使用する場合にはメモリの一部をデバッガが使うことで、OCDでのデバッグが可能になります。

D8H番地以降がユーザのプログラムです。それより前はオプションバイトや割り込みベクタテーブル等なので、通常はあまり気にする必要はありません。

デバッガをE2Liteからシミュレータにすれば、motファイルの値と同じになるはずです。

もぐら さん、こんにちは。NoMaYと申します。

チョコさんのリプライに追加しますと、

＞ RL78G13マイコンのコード・フラッシュメモリはCS+からのメモリダンプやプログラムからのリードでは確認することが出来ないのでしょうか？

そういうことでは無いです。オンチップデバッグ機能と関わりのある何箇所かの領域において、MOTファイルのHEXデータを書き換えて、マイコンのフラッシュメモリに書き込むようになっているのです。とっさの記憶では、以下の領域がMOTファイルと異なる値になっている筈です。

0x00番地,0x01番地:
MOTファイルではユーザプログラムのリセット番地、実際に書かれる値はオンチップデバッグ用モニタプログラムに関する何かのおまじないの値

0xCE番地～0xD7番地:
MOTファイルでは0xFF×10、実際に書かれる値はオンチップデバッグ用モニタプログラムに関する何かのおまじないの値

ROMの終わりの256バイトもしくは512バイト:
MOTファイルでは0xFF×256もしくは0xFF×512、実際に書かれる値はオンチップデバッグ用モニタプログラムの機能の一部分

あと、初学者さんへ伝えたいこととしては、ソフトウェアブレークポイントを設定するとフラッシュメモリの該当箇所の命令が(命令セット上は非公開の)ソフトウェアブレークポイント命令へとデバッガにより書き換えられます。ですので、その時にユーザプログラムで該当箇所を読むとMOTファイルとは異なる値が読めます。(デバッガのメモリウィンドウや逆アセンブルウィンドウでは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機能を使ってデバッグできるようにするための仕組みが問題の部分です。

これは、そんなものと思ってください。

チョコ様、NoMaY様
詳しくご説明していただき、ありがとうございました。
エミュレータを使用したデバッグによって、コードフラッシュの一部がデバッグ用に書き換わってしまうこと理解致しました。
CS+のシミュレータについて調べてみましたが、使用しているR5F101GFは残念ながら対象外のデバイスでした。
今回の件を質問させていただいた経緯と致しまして、起動時にコードフラッシュのサムチェックを行っていまして、
その比較するサム値をデバッガ上で求めようとしていました。
求めた値をmotファイルに記述して、ROMデバッグしたところ、サム値が異なっていたことを疑問に思い質問させていただきました。
マイコン機器に表示、通信する手段があれば、ROM上で計算したサム値を知ることが出来るのですが、無かった為デバッガ上で求めようと思いましたが、
それも難しいと分ったので、他の手段を考えてみたいと思います。
ありがとうございました。

G13_INTP9.zip

チョコです。

>CS+のシミュレータについて調べてみましたが、使用しているR5F101GFは残念ながら対象外のデバイスでした。

機能は限定されているかもしれませんが、命令のシミュレーションは可能です。

前回のプロジェクトをR5F101GFに変更して、INTP10をINTP9に変更して試してみましたが、INTP9やポートおよび外部部品も使えました。参考でプロジェクトのzipファイルを添付しておきました。

チェックサムの計算くらいは問題なくできるはずです。

なお、RL78/G13にはCRC計算機能が搭載されており、CC-RLの「プロパティ」の「ヘキサ出力オプション」で設定できます。

もぐら さん、こんにちは。NoMaYです。

もぐらさんのリプライとチョコさんのリプライで話が違っているような気がしましたので、シミュレータのドキュメントを探してみました。R5F101GFはシミュレータの対象デバイスになっていました。(ひょっとして別のグループ(例えばRL78/G10とか)のリリースノートを参照されたので対象外だと勘違いされたとか？)

RL78/G13, RL78/G13A用シミュレータ V2.00.01 リリースノート
R20UT4663JJ0100 Rev.1.00 Nov.20.19
www.renesas.com/jp/ja/document/rln/rl78g13-rl78g13a-simulator-v20001-release-note
R5F101GFを検索すると「RL78/G13,RL78/G13Aシミュレータのサポートするデバイス一覧」に見付かります。
　

チョコです。

".textf"と言われてもあまりに漠然としすぎています。

使用されているデバイスがR5F101GFということは、コードフラッシュは96Kバイトで、16ビットで

アクセスできる範囲（64kバイト）を超えているので、アクセス方法に問題があるような気がします。

チョコ様
お返事ありがとうございました。
情報が不足しておりまして申し訳ありませんでした。
サムチェックの領域はコードフラッシュ内の0x0000番地～0x300D番地までを対象としておりまして、
1バイト加算の総和をチェックサム値としておりました。
上記のサムチェックをCS+のシミュレータで実行し、motファイルにチェックサム値として埋め込み、
ROMで動作したところ、サム値が一致しなかったことから、どこのセクションで不一致が発生するかの切り分けとして、
セクション毎に上記と同じ手法(アドレス範囲の変更)でサムチェックを実施しました。
その時に、”.textf”セクションに該当します0x01A0番地～0x0D53番地におきまして、チェックサム値の不一致が発生したことから、
先日の質問をさせていただきました。
コードフラッシュのアクセス方法としましては__forをつけて20bitアクセスできるようにしております。(下記がサムチェックのプログラムとなります)
かふぇルネ様の検索機能で同じような質問を漁ってみたのですが、答えにたどり着けずにいます、、
　
--------------------------------
#define D_ROM_CHK_STR 0x000001A0
#define D_ROM_CHK_END 00000D54
#define D_CHK_SUM 0x00017DFC
　
unsigned long  endadr;
unsigned long  chkadr;
unsigned long  sumchk = 0;
　
chkadr  = (unsigned long)D_ROM_CHK_STR;
endadr = (unsigned long)D_ROM_CHK_END;
　
while( endadr >= chkadr )
{
 sumchk += (unsigned char)(*(__far unsigned char *)chkadr);
 chkadr++;
}
　
gChkSumView = sumchk;
　
if(*(__far unsigned long *)D_CHK_SUM != sumchk)
{
 while(1);

}