ターゲットRL78/G13で発生した問題ですが・・・・
R_main.cで定義したグローバル変数に値が入らない問題が発生して、頭を抱えていました。
定義した変数は、volatile uint16_t 型の1次元配列です。初期値を定義したら変数に値が入るようになった。(変な話です)
マップファイルの内容を確認する為に、変数/関数配列情報の出力オプションを有効にしたら何故かしら問題が解決ししました。
経験のある方は、おられませんか。
tanuさん、こんにちは。NoMaYです。> nop();その1でブレークしました。そうでしたか。念の為の再確認ですが、オンチップデバッグで実際に使われているマイコンはRL78/G13のR5F100xJもしくはR5F101xJなのですよね?具体的に型番は何でしょうか?> セルフプログラミング予約領域を避ける必要が有るかもしれません。実は、この実行時チェック区間でtanuさんのプログラムとしてセルフプログラミングが行われている訳ではないですので、理屈上は予約領域を避ける必要は無いはずなのです。予約領域の話がクローズアップされるケースは、ゼロクリアの実行時チェックに成功して、でも、ブレークしてウォッチウィンドウやメモリウィンドウで値を確認するとゼロクリアされてない、というケースなのです。
tanuさん、こんにちは。NoMaYです。#tanuさんの前2つのリプライの先頭行がコピペミスで私のリプライのようになっちゃってます> セクションの開始アドレス .bass/FB300で、なんと!クリアーされました。ということは、予約領域辺りが、Go実行中(というかステップ実行以外では)アクセス出来なくなってしまっているのかなぁ、、、今思い浮かんだ可能性(思い付き)なのですが、work_state_clear()関数が実行される時、既にセルフプログラミングモードに入っていたりする、ということはあったりするのでしょうか?(いや、でも、それだと、そもそもブレークしないとかステップ実行出来ない、とかだったかも、、、)マイコンの不良の可能性もあるのかなぁ、、、
tanuさん、こんにちは。NoMaYです。> E1の問題は考えられないでしょうか。プログラム実行中の、実行時チェックでゼロクリア出来なかったことが確認されたとなると、E1ハードウェアとかCS+ソフトウェアとか、そういった可能性は非常に考えにくいです、、、(この初期化処理と実行時チェックの僅かな期間の間に、それらがドンピシャリのタイミングで(たまたまにせよ)介入してくることは、非常に考えにくいのです、、、)とはいえ、CS+でのオンチップデバッグ中には起きるけれども、RFPでプログラムを書き込んだ場合には起きない、といった可能性はあるかも知れないです。ですが、そうなったとしても、上記の私の考えでは、E1ハードウェアとかCS+ソフトウェアとか、そういったものではなくて、マイコン自体の何かなのではないかなぁ、とは思うのです。(あと、tanuさんには失礼かと思いますが、プログラムの何かかも、という可能性は私は一応残しておくかな、と思います、、、)あと、この状況になったら、私ですと別の同一ボードを入手できないかとかマイコンを交換出来ないかとか、そういう算段を周りの人たちと相談し始めるかな、と思うのです。そうしても発生するのであれば、一応残しておいた可能性の、プログラムの何かかも、をもう一度考えてみるかな、と思うのです、、、
tanuさん、こんにちは。NoMaYです。これは、以下のようなことを確認して結果次第ではルネサスさんに報告する、というのが定番(セオリー)かな、という気がしてきました、、、(1) プログラムを極端に単純化して、0xFAF00に0を書いて0が書けたか確認するだけにする(0であればLED1を点灯、0でなければLED2を点灯、等)。(2) 同様なことを、0xFB300に対して行うプログラムを作る。(3) CS+上で、ステップ実行させた時はどうなるか、Go実行させた時はどうなるか、調べる。(4) RFPでマイコンにプログラムを書いた時はどうなるか調べる。(5) 複数のマイコンで同じ症状になるか調べる。
tanuさん、こんにちは。NoMaYです。> Bassを変更する前に電源ON後のウオッチデータは、0以外何らかの値が入っていました。> 変更後に、電源ON後は、0クリアーされています。プログラム起動前に、値をウオッチで書き込み初期動作を確認しました。昨日の返信によれば、この構造体配列は普通のBSS領域のようですので、本来はスタートアップルーチン内でゼロクリアされている筈のものですね。ですので、スタートアップルーチン内でもゼロクリア出来なかった(電源ON時の不定データのまま?)、ということかと思います。複数のマイコンで同様な症状ということですが、以下の(4)を確認することはされますか?> (4) RFPでマイコンにプログラムを書いた時はどうなるか調べる。
tanuさん、こんにちは。NoMaYです。> 注1. セルフ・プログラミング時およびデータ・フラッシュ書き換え時は,...> をFFE20H-FFEDFHの領域に配置しないでください。> また,R5F100xJ,R5F101xJ(x=F,G,J,L,M,P)のFAF00H-FB309Hの領域は各ライブラリで使用するため使用禁止になります。この文言のミソは「セルフ・プログラミング時およびデータ・フラッシュ書き換え時は」という箇所で、そうでなければ使用可能な筈なのです。例えば、RL78/G13のハードウェア編のUMですと、他にも以下の領域を「セルフ・プログラミングおよびデータ・フラッシュ書き換えを行う場合」にライブラリが使用します、という文面になっています、、、ただ、tanuさんが引用された文面は、これとは意味することが明らかに違いますね、、、どの資料から引用したか教えて頂けませんか?RL78/G13 ユーザーズマニュアル ハードウェア編 (おおっ、新しい版が出てる、、、)www.renesas.com/jp/ja/search/keyword-search.html#genre=document&q=r01uh0146r01uh0146jj0350_rl78g13.pdf131P「3. 1. 3 内部データ・メモリ空間...略...注意1. ...略...2 ....略...3. セルフ・プログラミングおよびデータ・フラッシュ書き換えを行う場合,フラッシュ・ライブラリが次に示す製品のRAM領域を一部使用します。対象製品とフラッシュ・ライブラリが使用するRAM領域のスタートアドレスを示します。R5F100xD, R5F101xD(x = 6-8, A-C, E-G, J, L) :スタート・アドレス FF300HR5F100xE, R5F101xE(x = 6-8, A-C, E-G, J, L) :スタート・アドレス FEF00HR5F100xJ, R5F101xJ(x = F, G, J, L, M, P) :スタート・アドレス FAF00HR5F100xL, R5F101xL(x = F, G, J, L, M, P, S) :スタート・アドレス F7F00Hフラッシュ・ライブラリが使用するRAM領域は、RL78ファミリセルフプログラミングライブラリセルフRAMリスト(R20UT2943)を参照してください。」そして、実は、このことが私の昨日の以下の質問に繋がるのです、、、(ただ、よくよく考えてみたら更に深刻なことが起きる筈だったような気がして、すぐに自分で否定しましたが、、、)> 今思い浮かんだ可能性(思い付き)なのですが、work_state_clear()関数が実行される時、既にセルフプログラミングモードに入っていたりする、ということはあったりするのでしょうか?(いや、でも、それだと、そもそもブレークしないとかステップ実行出来ない、とかだったかも 、、、)
tanuさん、こんにちは。NoMaYです。> www.marutsu.co.jp/.../r01uh0146jj0310_rl78g13.pdf> 少し古い資料ですね。私の前の返信同様にとっさに「3. 1. 3 内部データ・メモリ空間」を見たら私の前の返信と同様の記載でしたので、あれっ、と思い検索してみたら、型番毎のメモリマップの図のページにも記載があったのですね。そのページはR5F100xJ, R5F101xJの為のページなので、あのような文面だったのですね。最新版のハードウェア編のUMでも、そのページの記載に多少の違いはありましたが、大勢に変わりのない違いでした、、、私はこれで眠れなくなりそうですwww ただ、私の手元にあるRL78/G14 Fast Prototyping Boardに搭載されているR5F104MLAに同様の領域があることに気付きましたので、今週中に試してみようかと考え始めました、、、RL78/G13 ユーザーズマニュアル ハードウェア編 (新しい版の方です、、、)www.renesas.com/jp/ja/search/keyword-search.html#genre=document&q=r01uh0146r01uh0146jj0350_rl78g13.pdf117P「図3-8 メモリ・マップ(R5F100xJ, R5F101xJ(x = F, G, J, L, M, P, S))...図は省略...注1. セルフ・プログラミングおよびデータ・フラッシュ書き換えを行う場合,スタック,フラッシュ・ライブラリで使用するデータ・バッファ,ライブラリ関数の引数,ベクタ割り込み処理の分岐先やDMAによる転送先/転送元で利用するRAMアドレスをFFE20H-FFEDFHの領域に配置しないでください。また,R5F100xJ,R5F101xJ(x = F, G, J, L, M, P)は,フラッシュ・ライブラリがFAF00Hから一部のRAM領域を使用します。フラッシュ・ライブラリが使用するRAM領域は、RL78ファミリセルフ・プログラミング・ライブラリセルフRAMリスト(R20UT2943)を参照してください。」
NoMaYさんtanuです。
マニュアルを再度読み直してみて気づいた事が有ります。コード生成(設計ツール)→クロック発生回路→安全機能→RAMガード機能設定を、「使用する」の設定、RAM下位アドレス128バイトが、書き込み禁止設定をしていました。あまり意識が無く良かれと思って設定していました。まだ確認はしていませんが、関係するのではと・・。
tanuさん、こんにちは。NoMaYです。> コード生成(設計ツール)→クロック発生回路→安全機能→RAMガード機能設定を、「使用する」の設定、RAM下位アドレス128バイトが、書き込み禁止設定をしていました。情報どうもありがとうございます。まだ確認していないとのことですが、当たりっぽい、ですよね。安全機能に関しては、かふぇルネに投稿されていた話あたりのことぐらいしか私は知識に無くて、RAMに関してはパリティエラー、ガード機能に関してはSFRガード、しか頭に入っていなかったです。