CS+ cc V8.04.00 r_main.c グロバール定義の変数に値が入らない

ターゲットRL78/G13で発生した問題ですが・・・・

R_main.cで定義したグローバル変数に値が入らない問題が発生して、頭を抱えていました。

定義した変数は、volatile uint16_t 型の1次元配列です。初期値を定義したら変数に値が入るようになった。(変な話です)

マップファイルの内容を確認する為に、変数/関数配列情報の出力オプションを有効にしたら何故かしら問題が解決ししました。

経験のある方は、おられませんか。

 

Parents
  • tanuさん、こんにちは。NoMaYです。

    > nop();その1でブレークしました。

    そうでしたか。念の為の再確認ですが、オンチップデバッグで実際に使われているマイコンはRL78/G13のR5F100xJもしくはR5F101xJなのですよね?具体的に型番は何でしょうか?

    > セルフプログラミング予約領域を避ける必要が有るかもしれません。

    実は、この実行時チェック区間でtanuさんのプログラムとしてセルフプログラミングが行われている訳ではないですので、理屈上は予約領域を避ける必要は無いはずなのです。予約領域の話がクローズアップされるケースは、ゼロクリアの実行時チェックに成功して、でも、ブレークしてウォッチウィンドウやメモリウィンドウで値を確認するとゼロクリアされてない、というケースなのです。

  • tanuさん、こんにちは。NoMaYです。
    >オンチップデバッグで実際に使われているマイコンはRL78/G13のR5F100xJもしくはR5F101xJなのですよね?具体的に型番は何でしょうか?
    P5F100PJAです。
    セクションの開始アドレス .bass/FB300で確認します。
  • tanuさん、こんにちは。NoMaYです。
    セクションの開始アドレス .bass/FB300で、なんと!クリアーされました。
Reply Children
  • tanuさん、こんにちは。NoMaYです。#tanuさんの前2つのリプライの先頭行がコピペミスで私のリプライのようになっちゃってます

    > セクションの開始アドレス .bass/FB300で、なんと!クリアーされました。

    ということは、予約領域辺りが、Go実行中(というかステップ実行以外では)アクセス出来なくなってしまっているのかなぁ、、、

    今思い浮かんだ可能性(思い付き)なのですが、work_state_clear()関数が実行される時、既にセルフプログラミングモードに入っていたりする、ということはあったりするのでしょうか?(いや、でも、それだと、そもそもブレークしないとかステップ実行出来ない、とかだったかも、、、)

    マイコンの不良の可能性もあるのかなぁ、、、

  • NoMaYさん tanuです。
    E1の問題は考えられないでしょうか。
  • 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) 複数のマイコンで同じ症状になるか調べる。

  • NoMaYさん tanuです。
    すいません。コピペミスです。年取ってくると目が見えません。m(_ _)m
    CPUは、複数で確認しましたが、同様でした。
    気づいた事が一つあります。
    Bassを変更する前に電源ON後のウオッチデータは、0以外何らかの値が入っていました。
    変更後に、電源ON後は、0クリアーされています。プログラム起動前に、値をウオッチで書き込み初期動作を確認しました。
    別のトラブルですが、別のPCでCS+ CA-CXで、動作を確認しようとしたら、E1とターゲットが繋がらなくなりました。Windows10のアップデート等の関係が有るかもしれません。
  • tanuさん、こんにちは。NoMaYです。

    > Bassを変更する前に電源ON後のウオッチデータは、0以外何らかの値が入っていました。
    > 変更後に、電源ON後は、0クリアーされています。プログラム起動前に、値をウオッチで書き込み初期動作を確認しました。

    昨日の返信によれば、この構造体配列は普通のBSS領域のようですので、本来はスタートアップルーチン内でゼロクリアされている筈のものですね。ですので、スタートアップルーチン内でもゼロクリア出来なかった(電源ON時の不定データのまま?)、ということかと思います。複数のマイコンで同様な症状ということですが、以下の(4)を確認することはされますか?

    > (4) RFPでマイコンにプログラムを書いた時はどうなるか調べる。

  • NoMaYさん tanuです。
    CPUアーキテクチャ資料にこんな記事が有りました。
    注1. セ ル フ ・ プ ロ グ ラ ミ ン グ 時お よ び デ ー タ ・ フ ラ ッ シ ュ 書き 換え 時は ,ス タ ッ ク ,デ ー タ ・ バ ッ フ ァ ,ベ ク タ 割り 込み処理の 分岐先や DMA に よ る 転送先/転送元で 利用す る RAMア ド レ ス を FFE20H-FFEDFH の 領域に 配置し な い で く だ さ い 。 ま た ,R5F100xJ, R5F101xJ(x = F, G, J, L, M, P)の FAF00H-FB309Hの 領域は 各ラ イブ ラ リ で 使用す る た め 使用禁止に な り ま す 。
  • 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=r01uh0146
    r01uh0146jj0350_rl78g13.pdf
    131P

    3. 1. 3 内部データ・メモリ空間
    ...略...
    注意1.  ...略...
    2  ....略...
    3. セルフ・プログラミングおよびデータ・フラッシュ書き換えを行う場合,フラッシュ・ライブラリが次に示す製品のRAM領域を一部使用します。対象製品とフラッシュ・ライブラリが使用するRAM領域のスタートアドレスを示します。
    R5F100xD, R5F101xD(x = 6-8, A-C, E-G, J, L) :スタート・アドレス FF300H
    R5F100xE, R5F101xE(x = 6-8, A-C, E-G, J, L) :スタート・アドレス FEF00H
    R5F100xJ, R5F101xJ(x = F, G, J, L, M, P) :スタート・アドレス FAF00H
    R5F100xL, R5F101xL(x = F, G, J, L, M, P, S) :スタート・アドレス F7F00H
    フラッシュ・ライブラリが使用するRAM領域は、RL78ファミリセルフプログラミングライブラリセルフRAMリスト(R20UT2943)を参照してください。


    そして、実は、このことが私の昨日の以下の質問に繋がるのです、、、(ただ、よくよく考えてみたら更に深刻なことが起きる筈だったような気がして、すぐに自分で否定しましたが、、、)

    > 今思い浮かんだ可能性(思い付き)なのですが、work_state_clear()関数が実行される時、既にセルフプログラミングモードに入っていたりする、ということはあったりするのでしょうか?(いや、でも、それだと、そもそもブレークしないとかステップ実行出来ない、とかだったかも 、、、)

  • NoMaYさん tanuです。
    www.marutsu.co.jp/.../r01uh0146jj0310_rl78g13.pdf
    少し古い資料ですね。
    セクションの開始アドレスを指定するのですが、どうしても、他のセクションが使用禁止領域に配置されます。セクションを変えると2次被害があちこち出ますね。受信割り込みが動作しなくなりました。MAPで確認すると.dataRセクションが、禁止領域に配置されたようです。
    .bss/fb30a,.dataR/FD000設定で、何とか禁止領域に配置されないようになりました。
    今から動作確認します。
  • NoMaYさん tanuです。
    セクション指定の変更で、動作するようになりました。少し疑問は残りますが・・・・