RL78/G13のCRCチェック機構

スタッフのチョコです。

ご迷惑をおかけして申し訳ありません。

お問い合わせの高速ＣＲＣ機能については，サンプルコードとアプリケーションノートを準備中です。
サンプルコードそのものはできていて，現在ドキュメントの作成中です（来月末までには登録する予定です）。

具体的な処理としては，CRC0CTLレジスタを設定して，ＲＡＭ上のプログラムでHALT命令を実行することでCRC演算が行われます。（マニュアルの図22-3参照）

スタフのフィルです。

RL78をご使用いただきありがとうございます。

ご質問の件、”RL78/G13 ユーザーズマニュアル ハードウェア編　Aug.22.11Rev.1.00”のP902に記載の本機能の実行条件にご注意ください。

”「RAM上のプログラムによるメイン・システム・クロックでのHALTモードでのみ動作可能です。」”

従いまして、以下の手順で実行が可能です。
・R_CGC_Set_CRCOn(void)実行
・もしサブシステムクロック動作の場合、メインシステムクロック動作に切り替える
・RAM上に配置されたサブルーチンに遷移（RAMフェッチ）
・HALT実行

解答ありがとうございます。

おおむね理解しているつもりですが
最大の問題は肝心の想定されるCRC値が
うまく出力されていないようすだということです。
どこに出力されているのでしょう？
前にも書きましたが、CRC値はFFのままにみえるのです。

う～ん。

>サンプルコードそのものはできていて，現在ドキュメントの作成中です（来月末までには登録する予定です）。

ということであれば、もう少し早くいただけないですかねぇ。
完全なドキュメントでなくてもかまわないのですが。
月末には実装完なのですが、自前でROMチェックルーチン
つくるよりは遙かに確実なはずなので。

入手の方法はありませんか？

以下のような感じです。
HALTしてRETしてくると、PGCRCLはちゃんと返ってくるようです。
ハードウエアマニュアルどおりのうごきだとおもいます。

==========================================
unsigned char ChkHardwareCRC(void)
{
// HALT\, RET
char CRC_check_ram[] = {
0x61\, 0xED\, 0xD7\,
0\,0\,0\,0\,0\,0\,0\,0\,0\,0
};
unsigned int CRCvalue = 0;
unsigned int CRCvalue2 = 0;
unsigned char ret = 1;

//X_ROM_CRC_SUM : 0xFFFC サムの保存アドレス
__far int* const ptr = X_ROM_CRC_SUM;

// RAM アドレス内にHALT配置
void __far (*funcHALT)(void) = &CRC_check_ram[0];

CRC0EN = 1; // CRC演算動作許可

funcHALT(); // HALT実行

CRC0EN = 0; // CRC動作停止

CRCvalue = PGCRCL ;
CRCvalue2 = *ptr;


if ( CRCvalue != CRCvalue2 ) ret = 0;
else ret = 1;

return ret;
}

==========================================

問題は、
0xFFFCにサムアドレスがきちんと生成されていない
ということだとおもいます。
やりかたはあっているでしょうか？
CA78K0R（ビルドツール）をクリックして、
オブジェクト コンバート オプションのタブをひらく。
CRC演算の項目を
CRC演算を行う
CRC結果出力アドレス FFFC
CRC演算範囲 0h-0FFFBh
CRC演算方法 高速CRC
に設定。

もしかして、これだけではダメなんでしょうか？
あと一歩まできているとおもうんですが。
ヒントをいただければ、とおもうんですが。
よろしくお願いします。

スタッフのチョコです。

もしかすると，オンチップデバッグをオンにされてはいないでしょうか。

オンチップデバッグではＲＯＭの最後の512/256バイトを使用してしまいます。そのためにＣＲＣの値が出力されていないのではないかと思われます。

ＣＧのクロック設定のだけでなく，リンクオプションも確認してください。
落ちらで確認した画面を添付しておきます。

IqBqxnUnN4FUs6Xu-0_A0035.jpg

O0A8sRqgy1zIlK8h-1_A0036.jpg

オンチップデバッガ設定が原因でしたか！
たしかにFDFE以前だときちんとＨＥＸファイルには
指定アドレスで書かれるようです。
さすがにＥ１デバッガなしで開発、ってのは現実的で
ないので、CRCはFDEFにセットするようにして
運用しようとおもいます。

さて、あとすこしだとおもうのですが
もうすこしおつきあいください。

ＨＥＸにはきちんとＣＲＣが設定されているようなので
さきのＲＯＭ読み出しルーチンをやってみましたが
やっぱり失敗します。
いろいろためしてみると、コンパイルしたコードが
入っているアドレスに対してはきちんと読み出しが
できているようです。
これにたいし、コンパイルコードがはいっていない
ＲＯＭ領域についてはＦＦＦＦになる雰囲気なのです。

先にあげたＲＯＭ読み出しコードではなにかたりないのでしょうか？

スタッフのチョコです。

どうも，オブジェクト・コンバータ段階では，オンチップ・デバッグで使用する領域にはＦＦが埋まっているようです。
このため，オンチップ・デバッグが生きている状態では，ビルド時の値が実際に動作させるときの状態と一致しません。

こうなると，ＣＲＣチェックはオンチップ・デバッグしない状態で確認するしかないようです。

チョコさん
お手数おかけしています。
たしかにその領域はＦＦでうめられて、ＣＲＣも吐かれないので、了解です。

ただ、ず～っっと前のほうのエリア、たとえば、0300とか、コードが置かれるあたりのほうでためしているのですが、ＣＲＣはきちんと指定アドレスに埋め込まれています（ＨＥＸで確認）

これで、前回示したプログラムをうごかすと、
ＲＯＭコード部はちゃんと読み出せています。
（デバッガで読み出す値と逆アセンブラの値がきちんと一致して読み出せてます）
ところが、ＲＯＭコードのないところはＦＦ。
これは正しいのですけど、ＣＲＣをおいたところまでＦＦになるのは何か仕掛けがあるのかなと。

あと一歩だとおもうんですが．．．

tetnoguchi様

情報が大変遅くなり申し訳ございません。

オンチップデバッグを行う際、デバッグ用モニタ領域は、
消去するため、0xFFFCの領域もその対象になり、
期待値を埋め込んでおくことができません。

また、リセットベクタ(0x2番地)もデバッグ用途に
書き換えられますので、演算結果も異なってしまいます。

このためRL78/G13のオンチップデバッグでは
高速CRC機能の動作はできますが、肝心のチェックが
できません。
フルICEのIECUBEではチェックが可能です。