お世話になります。下記の環境で動作を行っております。
フラッシュモジュール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
以上です
シェルティさん。こんにちは、togashiです。
リプライありがとうございます。また、開発チームへのご確認ありがとうございます。
ご紹介いただいいたリンク(ルネサスMCUにおけるファームウェアアップデートの設計方針)のブートローダー方式として、方式①：バッファリング先=バンクの片方を実装しようとしております。
仕様の都合上、Ethernet経由でファームウェアアップデートを行うのですが、既にブートローダー部分(bank0)に置くプログラム(Ethernet通信,motファイル受信/変換,フラッシュ書き換え)はあります。ただ、フラッシュモジュールがRX65Nに非対応のため書き換えています。(元はRX62NのシンプルフラッシュAPIです。)
こういった経緯もありひとまずサンプルを動かしてbank0とbank１の割り当て方法を調べていたのですのが躓きが多く、何度もご質問するかとは思いますが、何卒よろしくお願いいたします。
シェルティです、こんにちは。
本スレッド内容をまだ詳細まで読み切れてないのですが、フラッシュモジュールの開発チームと相談した結果を持ってきました。引き続き本スレッドをウォッチさせていただきます。
------
[回答]
r_flash_rx 付属のサンプルについては、CS+/e2 studioでエラーが出ないよう改訂を目指します。
またr_flash_rx 付属のデュアルバンクのデモプログラムはバンク切り替えの動作そのものを確認することを想定しております。バンク0、バンク1それぞれ同時にプログラムをダウンロードしているのは、なるべく少ない手順でバンク切り替えの動作を確認できるようにするためであり、デバッグ時のユースケースを想定したものではありません。
適切なファームウェアアップデートの方針は以下アプリノートの考えをベースとして今後展開してまいります。
ご連絡とご回答、ありがとうございます。
詳細中の内容と同じになってしまいすが、デュアルバンクではなくリニアモードでの実行に変更する予定です。
なるべく少ない手順でバンク切り替えの動作を確認できるようにするためであり、デバッグ時のユースケースを想定したものではありません。
>承知いたしました。改訂と今後の展開について、ありがとうございます。
togashiさん
コメントありがとうございます。詳細についても追って本スレッド内容を確認してまいります。
リニアモードの件も承知しました。デュアルモードにするとファームウェアアップデートは簡単ですが、内蔵ROMの半分しか実際には使えないというデメリットも出てきてしまいます。故にリニアモードにブートローダ＋アプリを入れたいという要望も理解できます。さらに一方で以下アプリノートで言及するようにブートローダのセキュリティ要件として「古いファームに戻ってはいけない」というものもあり、リニアモードだとこれをうまく作りこみができません。
上記URLのような標準的なアプリノートとしては教科書的に作る必要があるので、こういったセキュリティ要件を守るためデュアルモードを利用するのがリーズナブルなのでそう書いているのですが、一方で実際問題そこまでセキュリティ強度を求めるようなシステムではない場合も多く、この場合はセキュリティを犠牲にする形でリニアモードを使い、ROMを最大限有効活用するのもそれもまたリーズナブルと個人的には思います。＃自分で上のアプリノート書いておいてなんですが
MCUの世界観における上記のような考え方はようやく標準化が進んできたかなといったところで、ここ数年で固まってくるかもしれませんね。たとえばRAファミリで採用しているMCUBootはマイコン用ブートローダの決定版になる可能性があると思います。
https://github.com/mcu-tools/mcuboot
インターネット技術の規格集(RFC)※を作っている団体(IETF)も規格化に乗り出しているようです。(wolfSSL社が日本語訳を出しています）
https://www.wolfssl.jp/draft-ietf-suit-architecture-11/
ただまだデファクトスタンダード化には時間がかかると思うのと、インターネット接続機能を持つ電子機器はファームウェアアップデート機能が求められつつある（法令的にもこのあたり整備が世界的に進んできています）ので、今のうちからMCUの世界観におけるファームウェアアップデートに関する要素技術開発を進めておくのは大変有意義であると思います。
引き続き情報交換させていただけますと幸いです。
※追記：RFCを「規格」というと語弊がありますね。RFCはあくまで「コメント集」です。https://ja.wikipedia.org/wiki/Request_for_Comments
リニアモード,デュアルモードのご説明ありがとうございます。設計方針やセキュリティ関連からもデュアルモードが必要になりそうですね…。ファームウェアアップデートに関する情報についても少しチェックしてみます。ご紹介ありがとうございます！