Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

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

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

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

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

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

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

 

  • 変なコードを書いてるか、値が入らないというのが勘違いのどちらかではないですか
  • 現象を再現できるプロジェクトをまるごと公開されると問題解決に協力してくれる方も出てくるのではないかと思います。
  • fujiaさん回答有難うございます。
    CS+ CACX V4.0400からの移植で、動作済のソースを移植して、発生した問題です。
    E1を使用したデッバグ中に、発覚しました。
    不思議な現象としては、ブレークポイントを置きシングルステップで変数の状態を確認すると値が入ります。
    PROジェクトを公開したいのですが、フォーラムでの公開方法がわかりません。ご教授ください。
  • 新規プロジェクト製作し、以下のプログラムで動作を確認しましたが同様な現象が再現しました。
    ***********************************************************************************************************************
    Pragma directive
    ***********************************************************************************************************************/
    /* Start user code for pragma. Do not edit comment generated here */
    /* End user code. Do not edit comment generated here */

    /***********************************************************************************************************************
    Global variables and functions
    ***********************************************************************************************************************/
    /* Start user code for global. Do not edit comment generated here */
    volatile uint16_t test_counter;
    /* End user code. Do not edit comment generated here */
    void R_MAIN_UserInit(void);

    /***********************************************************************************************************************
    * Function Name: main
    * Description : This function implements main function.
    * Arguments : None
    * Return Value : None
    ***********************************************************************************************************************/
    void main(void)
    {
    R_MAIN_UserInit();
    /* Start user code. Do not edit comment generated here */
    test_counter = 0;
    NOP();
    while (1U)
    {
    test_counter++;
    NOP();
    NOP();
    NOP();
    NOP();

    }
    /* End user code. Do not edit comment generated here */
    }
  • E1エミュレータの問題かもしれません。
    シュミレータでは、問題が再現しません。
  • In reply to tanu:

    > PROジェクトを公開したいのですが、フォーラムでの公開方法がわかりません。

    投稿するコメントを入力する際に Reply ボタンの隣の Use rich formatting をクリックするとドラッグアンドドロップ等で投稿コメントに .zip ファイルを添付できるようなります。
  • In reply to tanu:

    制御CPU.zip

    プロジェックトファイルです。

    CS+ CACX開発環境ではこのような経験は有りません。CS+ CCと何か違いが有るのでしょうか。

  • tanuさん、こんにちは。NoMaYと申します。

    > シュミレータでは、問題が再現しません。

    過去、ビルド時のマイコンの型番とオンチップデバッグで実際にデバッグに使用していたマイコンの型番が違うことによる下記トラブル事例があったことを思い出しました。その辺りは大丈夫ですか?

    RL78 CS+のシュミレート と E1エミュレータ での設定の差
    japan.renesasrulz.com/cafe_rene/f/002-2095199602/6299/rl78-cs-e1

    switch 文使用時の挙動 (最適化なし時)
    japan.renesasrulz.com/cafe_rene/f/forum18/6147/switch

    もちろん、以下の点などは謎のままですけれども。(以下の1番目と2番目は上記と関連がありそうな予感はします。)

    > シングルステップで変数の状態を確認すると値が入ります。

    > 初期値を定義したら変数に値が入るようになった

    > 変数/関数配列情報の出力オプションを有効にしたら何故かしら問題が解決
     

  • NoMaYさん回答有難うございます。
    マイコン型式を確認しましたが、同じでした。

    変数/関数配列情報の出力オプションを有効にしたら何故かしら問題が解決した様に見えましたが、構造体の変数が特に変です。
    構造体のメンバーもvolatile指定しています。
    typedef struct tagWork_State { /* ステージ遷移登録テーブル */
    volatile uint8_t work_stage_no; /* 現在のワークがいるステージ */
    volatile uint8_t work_OkNg; /* 検査結果 OKorNG */
    volatile uint16_t stage_distance_count[stage_num]; /* ワーク検出からステージ1検査までの距離mm */
    // ステージ0はワーク検出ステージであるため常に0
    volatile uint16_t g_test_led_distance_count[stage_num]; // [0]照明点灯開始距離カウンタ
    // [1]照明消灯距離カウンタ
    } Work_State;

    volatile Work_State g_work_state[Work_No_num] ; /* ワークステージ状態構造体の実態 */

    起動時に、変数の初期化を行っていますが、ウオッチで確認すると初期化した値が入らないです。
    謎です。
  • tanuさん、こんにちは。NoMaYです。

    そうでしたか。大丈夫でしたか。以下の情報から考えると、私の場合、次のようなステップを踏むかと思います。

    > 起動時に、変数の初期化を行っていますが、ウオッチで確認すると初期化した値が入らないです。

    (0) 変数の初期化を行っている部分を、逆アセンブルウィンドウでステップ実行して、コードの動作を把握する
    (1) メモリに書いている命令(変数の初期化)の実行後、書き込んだアドレスのメモリの内容をメモリウィンドウで調べる
    (2) メモリの内容が期待した値でなければ、メモリウィンドウ上で値を変更出来るか調べる
    (3) メモリウィンドウ上で値を変更出来たなら、メモリに書いている命令のステップ実行でメモリの値が書き込んだ値にならない点にフォーカスした画面コピーを投稿する
    (4) メモリの内容が期待した値であれば、メモリウィンドウとウォッチウィンドウの表示が合わない点にフォーカスした画面コピーを投稿する
    (5) メモリウィンドウ上で値を変更出来なかったら、画面コピーを投稿する前に、何が起きていそうか再度考えてみる

    既に調べられているかも知れないですけど、画面コピーを見てみないと、うまく状況把握出来ないです。

  • In reply to NoMaY:

    NoMaYさん、tanuです。

    ステップ実行で、確認すると構造体変数に値が入りますが、ループ終了でブレークし確認すると値が入りません。ウオッチの値を直接変更は可能です。また、メモリの内容もステップでは変わっていますが、構造体配列の場合に問題が発生します。通常の配列は、初期化されます。

    g_work_state[0]がステップ実行後の変数値で、g_work_state[1]以降がforループ終了時の変数値です。

    g_test_led_off_distance_count[]の配列は、問題なく初期化されます。

  • In reply to tanu:

    tanu様
    鈴木と申します。定義している変数に volatileをつけるとどうなるでしょうか
    代入しかしていない変数ですと、コンパイラの最適化によっては
    省略されることもあります。以上、よろしくお願いします
  • In reply to 鈴木:

    回答有難う御座います。
    全ての変数に、volatileは必ず付けています。
    最適化は、嫌な経験が有りますので、コンパイラオプションも外しています。
  • In reply to tanu:

    tanu様、回答ありがとうございます。コード生成をお使いですね。
    変数の初期化を R_Systeminit()関数内で行っていないでしょうか?
    このハードウェア関連の初期化を行った後にRAMの初期化が実行されるので
    変数もクリアされます。(cstart.asm をご参照ください)
    以上、よろしくお願いします
  • In reply to tanu:

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

    このソースコードであれば、次に確認したいことは、構造体初期化ループのループ終了条件に使用されている Work_No_num の値ですね。ソースコードによれば関数内ローカル変数では無いですし、逆アセンブル結果を見たところファイル内スタティック変数でもグローバル変数でも無いですので(逆アセンブル結果内に _Work_No_num を参照している箇所が無いですので)、#defineで値は 8 でしょうか?あと、 stage_num も同様に推測して、#defineで値は 5 でしょうか?

    それで、画面コピーの状況は以下のような手順での結果でしょうか?

    (1) 33行目以降のforループをi=0の初回だけはステップ実行した
    (2) i=1以降に関してはGo実行した

    また、今までの文面とあわせると以下のことでよいですか?

    (3) i=1以降に関しても、ステップ実行すると、期待したとおりに構造体配列がゼロクリアされる
    (4) 逆にi=0に関しては、Go実行させると、期待したとおりには構造体配列はゼロクリアされない

    そういう状況ですと、私が次に気になるのは以下の点です。

    (A) SPの値は幾つでしょうか?
    (B) ステップ実行で71行目に到達した時とGo実行で72目に到達した時と、どちらも i の値は 8 でしょうか?

    もっとも、work_state_clear()関数からはリターン出来ているようですので、可能性は低いか、ぎりぎりの状況だったか、という感じではありますけれど。

    あと、ウォッチウィンドウでの構造体配列g_work_state[]のアドレス表示によれば、この場所はR5F100xJ/R5F101xJのRAM領域の下端付近(下端が0xFAF00で構造体配置アドレスが0xFAF04)ですね。この場所はセルフプログラミングの予約領域で、デバッガもダウンロード時やソフトウェアブレークポイント設定/解除時はセルフプログラミングを使用しているのでデバッガの内部処理的には複雑なことが行われている領域ではあります。(もちろん変なことが起きないように辻褄合わせは念入りに行われているはずですが。) 対症療法的に、この予約領域をリンカのセクション設定で避けるようにすると回避出来る可能性もあるかもと思います。(予約領域は0xFAF00~0xFB2FFですね。)

    上の話は、対症療法というかデバッグの一環としてというか、そういうものですが、デバッグの一環として思い浮かぶ技法として、以下のような実行時チェックルーチンを埋め込んでみる手があります。(何が起きているのか、もう少し把握するためですけれど。)

    (a) 33行目からの for( i = 0; i < Work_No_num; i++ ){...} のループが終了した後、同様にfor( i = 0; i < Work_No_num; i++ ){...} のif文で構造体配列が期待したとおり 0 に初期化されているか確認する以下のようなコードを挿入して、Go実行させてみる。

        for( i = 0; i < Work_No_num; i++ ){
            既にある初期化ルーチン
        }

        以下のようなコードを挿入してみる
        for( i = 0; i < Work_No_num; i++ ){
            uint8_t Not_Initilized = 0;
            if( g_work_state[i].work_stage_no != 0){
                Not_Initilized = 1;
            }
            上記と同様なコード
            if( Not_Initilized != 0 )
            {
                nop(); その1 ← ここにハードウェアブレークを設定する(ソフトウェアブレークを出来るだけ避けてみる)
            }
        }
        nop(); その2 ← ここにハードウェアブレークを設定する(同上、ただしハードウェアブレークが1本なら上記と排他で設定する)

    こんな感じで様子を見てみる、という手もあるかと思いました。これで何が分かるかというと、Go実行している最中にはきちんと一度は初期化されているのかどうか、ということがわかるかと思います。(厳密には、想定外の場所を初期化していた、という可能性が残りますが。)

    (イ) 実行時チェックで失敗する(上記のnop() その1でブレークした) → すぐに次のステップに進める訳ではないですが情報としては有用だと思います
    (ロ) 実行時チェックに成功する(上記のnop() その1でブレーしなかった) → デバッガの不具合の可能性が濃厚になると思います

    ちなみに、通常配列g_test_led_off_distance_count[]はアドレスが0xFFE88ですので、くだんの構造体配列とはかなり離れた場所にありますね。

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page