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次元配列です。初期値を定義したら変数に値が入るようになった。(変な話です)

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

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

 

  • In reply to tanu:

    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=r01uh0146
    r01uh0146jj0350_rl78g13.pdf
    117P

    図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)を参照してください。

  • In reply to NoMaY:

    NoMaYさんtanuです。

    マニュアルを再度読み直してみて気づいた事が有ります。コード生成(設計ツール)→クロック発生回路→安全機能→RAMガード機能設定を、「使用する」の設定、RAM下位アドレス128バイトが、書き込み禁止設定をしていました。あまり意識が無く良かれと思って設定していました。まだ確認はしていませんが、関係するのではと・・。

  • In reply to tanu:

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

    > コード生成(設計ツール)→クロック発生回路→安全機能→RAMガード機能設定を、「使用する」の設定、RAM下位アドレス128バイトが、書き込み禁止設定をしていました。

    情報どうもありがとうございます。まだ確認していないとのことですが、当たりっぽい、ですよね。安全機能に関しては、かふぇルネに投稿されていた話あたりのことぐらいしか私は知識に無くて、RAMに関してはパリティエラー、ガード機能に関してはSFRガード、しか頭に入っていなかったです。

  • In reply to NoMaY:

    NoMaYさん 各位殿
    tanuです。
    謝罪
    「コード生成(設計ツール)→クロック発生回路→安全機能→RAMガード機能設定を、「使用する」の設定、RAM下位アドレス128バイトが、書き込み禁止設定をしていました。」
    RAMガード機能設定を無効にして、動作に問題ありませんでした。
    原因は、私の設定ミスでした。
    皆さんの貴重な時間を無駄にした事を謝罪します。
    誠に申し訳ございませんでした。
  • In reply to tanu:

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

    > 「コード生成(設計ツール)→クロック発生回路→安全機能→RAMガード機能設定を、「使用する」の設定、RAM下位アドレス128バイトが、書き込み禁止設定をしていました。」
    > RAMガード機能設定を無効にして、動作に問題ありませんでした。

    良かったです。これで合点がいったので私は眠れそうです。コード生成機能の安全機能の設定画面は過去に何度も自分で画面コピーを採って投稿に貼り付けていたのですが、今回、RAMガードに関してはまったく思い浮かばなかったです、、、(私は、今回のおかげで、というのも変ですけど、次はもっとうまくアドバイスが出来そうな気がします、、、)

    [追記]

    つい先日、コード生成機能が安全機能を有効にするタイミングについて、かふぇルネでのやり取りを見掛けたのですが、ことRAMガードに関しては、そもそも最初からガードを掛けておくものでは無いような気もしますね、、、ユーザが大事なデータを書いた後、ユーザがガードをONしないといけない、そういうものであるような気がしますね、、、

  • In reply to NoMaY:

    NoMaYさんtanuです。

    もう一つの疑問

    「同じ安全機能の設定で、CS+ for CA,CX環境で動作していた。」

    この疑問が残ります。

    mapファイルを比較すると

    CS+ for CA,CX環境

    安全機能の設定で、リードオンリーになっているRAMエリアが、SELFRAM領域に定義されています。

    CS+ CC環境

    SELFRAM領域の定義が有りません。

    ルネサスのマニュアルも改定が多く、現状のコンパイラがどのような変数配置されるかチンプンカンプンです。

    解りやすいマニュアルが有ればご教授ください。

     

     

     

  • In reply to tanu:

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

    たぶん、私がtanuさんにうまく伝えることが出来ていないことがある、と思います。

    ・セルフプログラミングを行っていないのであれば予約領域を空けておく必要は無いのです
    ・RAMガードはRL78/G13の全ての型番で設定可能ですが、セルフプログラミング時に予約領域を空ける必要があるのは一部の型番のみなのです
    ・RAMガードによりガードされる領域とセルフプログラミングライブラリ予約領域は別の概念/領域なのです(たまたま特定の型番では領域が重なってしまっているのです)

    そこがうまく伝えられていないのでtanuさんは混乱しているのかな、と思うのです。

    [追記]

    別の言い方をすると、以下になります。

    ・RAMガードをONにしただけでSELFRAM領域が確保されてしまったなら、それはCS+ for CA,CXやCA78K0Rのバグだと思います。(ただ、CA78K0RでSELFRAM領域を意識したことがないので何とも言えませんが、例えば、セルフプログラミングを行おうが行うまいがCA78K0Rでは一律に特定の型番では予約領域を空けてしまっているかも知れません。そうであれば、それはもう、CA78K0Rというのはそういうもの、ということになるのかな、と思うのです。)

  • In reply to NoMaY:

    NoMaYさんtanuです。
    全ての謎が解けました。
    これで、CS+ CCを信頼して(少し不安・・)使えそうです。
    有難う御座いました。

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