お世話になります。下記の環境で動作を行っております。
フラッシュモジュールFIT(r_flash_rx)のデュアルバンク機能を用いて、コードフラッシュメモリ書き換えを行っております。サンプル(flash_demo_rskrx65n2mb_bank0_bootapp/flash_demo_rskrx65n2mb_bank1_otherapp)で、デュアルバンク機能を使用してデバックしようとしたところ、プロジェクトのロードがうまくいかず、投稿いたしました。
フラッシュモジュールFITのマニュアル5.3.1.2に沿って行っていますが、開発環境がCS+のため3の手順方法が異なります。そこで、下記の方法で取り組んでみましたが『アドレス範囲が不正です』となります。方法としては、
をおこなっています。bank1側のROM領域のセクションアドレスを0xFFF0000に変更した場合、ダウンロード自体はできますが、デバック上でメモリを確認してもコードに割り当てがされておりません…。この状況について、
※サンプルプロジェクトは一度e2studioでインポートした後、CS+用にエクスポートしております。
togashiさん、こんにちは。NoMaYです。本件は、以下のスレッドでの話題と共通する部分がありますね。私の今の印象では、そもそも、FITモジュールのデモプログラムに関する手順が不適切である、という気がするのです。ファームウェアのロードに失敗する。【デュアルバンク】【RX72N】japan.renesasrulz.com/cafe_rene/f/forum5/7269/rx72n/38776#38776不適切な点■ オプションメモリ領域のデータを含むMOTファイルをオフセットを付けてダウンロードしたら、当然ながら、オプションメモリ領域のデータは頓珍漢なアドレスへとズレてしまいます。ですので、デバッガでちゃんとしたエラーチェックをしていたら、当然ながら、エラーになってしまうと思うのです。e2 studioの事情◆ どうしてそんな手順が記載されているのかというのを推測すると、e2 studioがエラーチェックしてなかったので、不適切な点があることに手順の作成者が気付かなかったのだと思います。そんな中、e2 studioがエラーチェックするようにバージョンアップされたら、当然ながら、手順通りにやろうとするとエラーになって、手順通りに出来なかった、というのが上のスレッドの顛末です。(どうも、その後のバージョンでe2 studioはエラーチェックを再び無くしたようです。(と私は認識しています。))CS+での対策● 上記のスレッドに書いたe2 studioでの対策と同じです。「対策としては、以下が考えられます。(A) e2 studio上でバンク1へダウンロードするプログラムのソースからオプション設定メモリデータを取り除く(B) e2 studio上でバンク1へダウンロードするプログラムとしてMOTファイルを使ってCC-RXでMOTファイル化する時にリンカオプションにてオプション設定メモリデータを除外するようにする(手っ取り早くには手作業でエディタでMOTファイルを直接編集して取り除く手もあります)(C) 他方、本番(という表現で伝わるか自信が無いですが)で使うMOTファイルをXMODEMで送信した場合に、受信側でオプション設定メモリデータを無視するように作り込まれている可能性もあるかも？とも思います。(なので、MOTファイル化する時にCC-RXのリンカでオプション設定メモリデータを取り除く方法が分からない時、エディタでMOTファイルを直接編集してしまうことで事足りてしまうかも知れません。)」あと、以下の件は、こうなります。＞ ダウンロードするファイルからオフセットで追加した場合、RAM領域やROM領域(0x0FFFFFFFCのRESETVECT)は移動されるのでしょうか。RAM領域: MOTファイルにはRAM領域へ直接ダウンロードされるデータは含まれません。(というか含まれないようにMOTファイルを作るのが普通です。) RAM領域はビルド時の設定のままです。(オフセットを付けてダウンロードした場合でもMOTファイル内のコード自体/データ自体は変わらないです。)RESETVECT: こちらも同様に、オフセットを付けてダウンロードした場合でもMOTファイル内のRESETVECTデータは変わらないです。(MOTファイル内のRESETVECTデータがそのままダウンロードされます。)ただ、以下は何をされたのか推測出来ませんでした。＞ bank1側のROM領域のセクションアドレスを0xFFF0000に変更した場合、ダウンロード自体はできますが、デバック上でメモリを確認してもコードに割り当てがされておりません…。
こんにちは。NoMaYです。アプリケーションノートに記載された手順に従ってやろうとしても出来ない、という点はアレなのですけれども、アプリケーションノートのその辺りを読んで思ったのは、両方のプログラムを書き込んだとしても何をデバッグするのかな？とも思いました。(まさにデモの為に必要であるということは除いて、ですけれども。)ブート領域とフラッシュ領域のデバッグであれば、(私自身はそれがポピュラーなのか分かりませんが、ルネサスさんのアプリケーションノート的には)(RL78であれば割り込みベクタの取り扱いの件はあるもののそれ以外でも)両領域を何度も行き来するという話は分からなくは無いですけれども、デュアルバンクの場合は、書き換えて、リセットして、書き換えた後のバンクでブートする、という一方通行的な遷移のイメージしか思い浮かばなくて、その部分のデバッグをする時は、デバッガで事前に両方ダウンロードしても、片方はユーザが自前で書き換えてしまうので、書き換えてしまう方を事前にダウンロードしておく必要があるデバッグのユースケースが思い浮かばないなぁ、と思ったのです、、、(まさにデモの為に必要であるということは除いて)何があるだろうか、、、
togashiさん、NoMaYさん
シェルティです。こんにちは。
本件、フラッシュモジュールFIT(r_flash_rx)の開発チームに確認をお願いしておきました。進展ありましたらまた書き込みます。
個人的に思うにオプション設定メモリが含まれているのはチョンボで、ユースケースについてはデモの為だけ（バンクがひっくり返りますというだけ）なのかなと思います。
ファームウェアアップデートを実システムに適用するとしたら以下のようなことを考える必要があり、なかなかフラッシュ書き換えモジュール単体でどうこう説明する話でもないかなとも思いつつ、ファームウェアアップデートの見せ方としてもっと共通化していく必要があるとも感じております。
https://www.renesas.com/us/ja/document/apn/renesas-mcu-firmware-update-design-policy-rev100
以上です
NoMaYさん。こんにちは、togashiです。
リプライありがとうございます。過去の投稿と(A)~(C)を参考に、CS+上でr_bsp>mcu>rx65n>vecttbl.cの#if defined(__CCRX__)以降のオプション設定メモリデータの部分を削除いたしました。mapファイルでもオプションメモリ設定関連の$ADDR_Cのアドレスが表示されなくなりました。
この設定で再度オフセット0xFFF00000でダウンロードしましたが、やはり『アドレス範囲が不正です』と表示になります。おそらくbank1側のセクション設定0xFFFFFF80:EXCEPTVECTと0xFFFFFFFC:RESETVECTがアドレス範囲外になる影響かとおもいます。EXCEPTVECTはセクション設定からアドレスを変えられますが、RESETVECTはアドレスが固定のため変更してもbank1側のリセット後の動作が停止(暴走)するかと思います。(https://ja-support.renesas.com/knowledgeBase/19341095)
ただ、以下は何をされたのか推測出来ませんでした。>bank1側のROM領域のセクションアドレスを0xFFF0000に変更した場合、ダウンロード自体はできますが、デバック上でメモリを確認してもコードに割り当てがされておりません…。
>>こちらに関してはbank0側のROM領域のセクション設定を0xFFE00000から、bank1側のROM領域のセクションを0xFFF0000としてダウンロードしてます。(オフセットは0)。その場合ダウンロード後のデバック上のメモリ配置を確認できない、とのことでしたが再度やってみたら確認できました。ただ、ダウンロード後にプログラムが停止(暴走)します。bank0のデバッグのメモリ画面で、RESETVECT：0xFFFFFFFCを確認すると、bank1の内容がかかれているため暴走するのかと思います。
複数プログラムを書き込む場合の、RESETVECTの設定方法もしくは、自動配置等ありますでしょうか？
両方のプログラムを書き込んだとしても何をデバッグするのかな？とも思いました。(まさにデモの為に必要であるということは除いて、ですけれども。)
>bank0にbank1の書き換えとバンク切り替え用プログラムを実装しようとしています。そこで、バンク切り替え実行前まででbank1を書き換えられたかをデバック上で確認したい、という取り組みでした。(おっしゃるようにデモ動作もあります。)
シェルティさん。こんにちは、togashiです。
リプライありがとうございます。また、開発チームへのご確認ありがとうございます。
ご紹介いただいいたリンク(ルネサスMCUにおけるファームウェアアップデートの設計方針)のブートローダー方式として、方式①：バッファリング先=バンクの片方を実装しようとしております。
仕様の都合上、Ethernet経由でファームウェアアップデートを行うのですが、既にブートローダー部分(bank0)に置くプログラム(Ethernet通信,motファイル受信/変換,フラッシュ書き換え)はあります。ただ、フラッシュモジュールがRX65Nに非対応のため書き換えています。(元はRX62NのシンプルフラッシュAPIです。)
こういった経緯もありひとまずサンプルを動かしてbank0とbank１の割り当て方法を調べていたのですのが躓きが多く、何度もご質問するかとは思いますが、何卒よろしくお願いいたします。
togashiさん、こんにちは。NoMaYです。＞ この設定で再度オフセット0xFFF00000でダウンロードしましたが、やはり『アドレス範囲が不正です』と表示になります。その時のエラーメッセージの画面コピーを見せて頂けませんか？(CS+がエラーとしたアドレスが表示されている筈ですので、そのアドレスが知りたいです。)＞ 仕様の都合上、Ethernet経由でファームウェアアップデートを行うのですが、既にブートローダー部分(bank0)に置くプログラム(Ethernet通信,motファイル受信/変換,フラッシュ書き換え)はあります。この文面から推測しますと、最終的な使い方は、デュアルバンクモードでは無くて、リニアモードでの使い方になりそう、ですね。方式②っぽい気がしたのです。
１． 方式①：バッファリング先 = バンクの片方(デュアルバンク/バンクスワップ機構を使用)２． 方式②：バッファリング先 = バンクの片方(デュアルバンク/バンクスワップ機構を未使用)３． 方式③：バッファリング先 = 外部メモリ(EEPROMやシリアルフラッシュ)
＞ ただ、フラッシュモジュールがRX65Nに非対応のため書き換えています。(元はRX62NのシンプルフラッシュAPIです。)これは、FITのRXフラッシュモジュールがRX65N対応済みなのを知っていても、それでも過去の経緯上、シンプルフラッシュAPIの改造版を使い続ける必要があるので、ということになりますか？それとも、FITのRXフラッシュモジュールがRX65N対応済みなのを知らずに、そうされていますでしょうか？
その時のエラーメッセージの画面コピーを見せて頂けませんか？(CS+がエラーとしたアドレスが表示されている筈ですので、そのアドレスが知りたいです。)
>オプションメモリ設定の削除後、オフセットを0xFFF00000に設定した場合のエラー画面です。
左がbank0、右がbank1のセクションの設定になります。
この文面から推測しますと、最終的な使い方は、デュアルバンクモードでは無くて、リニアモードでの使い方になりそう、ですね。
>こちらの理解が甘くて申し訳ないのですが、詳細を教えていただけないでしょか。bank0(ブートローダー),bank1(メイン)としようとしており、bank0でbank1の書き換え/書き換え後のバンク切り替えを行おうと検討しています。そうするとバンク領域の選択が必要になるので、デュアルバンクになると認識だったので…。
これは、FITのRXフラッシュモジュールがRX65N対応済みなのを知っていても、それでも過去の経緯上、シンプルフラッシュAPIの改造版を使い続ける必要があるので、ということになりますか？それとも、FITのRXフラッシュモジュールがRX65N対応済みなのを知らずに、そうされていますでしょうか？
>すみませんこちらは誤記です。フラッシュモジュールがRX65Nに非対応のため書き換えています。ではなく、『シンプルフラッシュAPIがＲX65Nに未対応なので、フラッシュモジュールに書き換えています。』が正しいです。元々のプログラムがRX62Nで動作し、フラッシュの書き換え部分にシンプルフラッシュAPIを使用しおりました。シンプルフラッシュAPIはRX65Nでは未対応とのことだったので、FITのRXフラッシュモジュールに置き換えている、という意味合いです。(シンプルフラッシュAPIはRX65Nでは使用できない認識でいます。)
togashiさん、こんにちは。NoMaYです。まず、デモプログラムについてですが、このデモプログラムに関しては、ROMの開始番地を0xffe00000とするものでは無いです。このデモプログラムはバンクスワップのデモですので、ROMの開始番地を0xfff00000とするものなのです。2MBのROMを1MB+1MBの二つに見立てて、ある時は以下の(A)、またある時は以下の(B)、という具合に切り替わる(バンクスワップ出来る)ことをデモするものです。なので、ビルド時はどちらのプログラムもROMが1MBの設定でビルドされなければいけないものなのです。(A) ダウンロード時に下位アドレス側の1Mに書いたものが実行時にも下位アドレス側の1Mに位置する ダウンロード時に上位アドレス側の1Mに書いたものが実行時にも上位アドレス側の1Mに位置する(リセットベクタはこっち)(B) ダウンロード時に下位アドレス側の1Mに書いたものが実行時には上位アドレス側の1Mに位置する(リセットベクタはこっち) ダウンロード時に上位アドレス側の1Mに書いたものが実行時には下位アドレス側の1Mに位置するまず、この点は理解出来ますでしょうか？
ご説明ありがとうございます。『2MBのROMを1MB+1MBに見立てているため、ROMの開始番地は0xFFF00000にする』ということは理解できましたが、(A),(B)のバンクスワップでのリセットベクタがうまく理解できません。
bank0,bank1のプログラムがロードできた場合、アドレスとしては下記のようになるのでしょか？
下位アドレス側のプロジェクトで上位アドレス側を追加でダウンロードした場合
(A) ダウンロード時に下位アドレス側の1Mに書いたものが実行時にも下位アドレス側の1Mに位置する
>リセットベクタは下位アドレス側のリセットベクタ ダウンロード時に上位アドレス側の1Mに書いたものが実行時にも上位アドレス側の1Mに位置する(リセットベクタはこっち)
>リセットベクタは上位アドレス側のリセットベクタに設定？
このようなイメージでしょうか…？
togashiさん、こんにちは。NoMaYです。ああ、下位アドレスと上位アドレスという言葉の使い方が、私とtogashiさんで、逆なのですね、、、書き直してみました。(そういうこと、たまにありますね、、、)(A) ダウンロード時にFFE0_0000-FFEF_FFFFに書いたものが実行時にもFFE0_0000-FFEF_FFFFに位置する ダウンロード時にFFF0_0000-FFFF_FFFFに書いたものが実行時にもFFF0_0000-FFFF_FFFFに位置する(リセットベクタはこっち)(B) ダウンロード時にFFE0_0000-FFEF_FFFFに書いたものが実行時にはFFF0_0000-FFFF_FFFFに位置する(リセットベクタはこっち) ダウンロード時にFFF0_0000-FFFF_FFFFに書いたものが実行時にはFFE0_0000-FFEF_FFFFに位置する