お世話になります。下記の環境で動作を行っております。
フラッシュモジュール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です。ああ、下位アドレスと上位アドレスという言葉の使い方が、私と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に位置する
NoMaYさん。こんにちは、togashiです。
ご説明ありがとうございます。ズレがわかってよかったです…!
(A)がバンク選択機能で(B)がバンクスワップ機能なのかと認識しています。
また、FFE0_FFFF-FFEF_FFFとFFF0_0000-FFFF_FFFFではそれぞれ別のプロジェクトである、というイメージでいます。そうするとプロジェクトごとにリセットベクタが存在すると思うのですが、実行時に選択したリセットベクタが優先されるという意味合いでしょうか?
togashiさん、こんにちは。NoMaYです。> (A)がバンク選択機能で(B)がバンクスワップ機能なのかと認識しています。いえ、それは違うかなと思う。バンク選択機能=バンクスワップ機能=(A)と(B)を切り替えることが出来る機能、というのが適切かなと思うのです。以下にいくつかマニュアルの画面コピーを貼ってみました。あと、くだんのデモプログラムで、あのやり方でダウンロードした場合にどう配置されるかも画面コピーに書き込んでみました。(ひょっとしたら、フラッシュオプション設定メモリにBANKSELレジスタのBANKSWP[2:0]ビットというものがあることが分かったら理解が進むかも知れないと思いました、、、)RX65Nグループ、RX651グループ フラッシュメモリ ユーザーズマニュアル ハードウェア インタフェース編www.renesas.com/jp/ja/document/mah/rx65n-group-rx651-group-flash-memory-users-manual-hardware-interface-rev210RX65Nグループ、RX651グループ ユーザーズマニュアル ハードウェア編www.renesas.com/jp/ja/document/mah/rx65n-group-rx651-group-users-manualhardware-rev230RXファミリ フラッシュモジュール Firmware Integration Technology アプリケーションノートwww.renesas.com/jp/ja/document/apn/rx-family-flash-module-using-firmware-integration-technologyくだんのデモプログラムの場合
togashiさん、こんにちは。NoMaYです。> 仕様の都合上、Ethernet経由でファームウェアアップデートを行うのですが、既にブートローダー部分(bank0)に置くプログラム(Ethernet通信,motファイル受信/変換,フラッシュ書き換え)はあります。デュアルモードを使う場合は、以下のようになりますので、「ブートローダー部分(bank0)に置く」という使い方ではなくなりますね。BANK0 = ブートローダーL(Ethernet通信,motファイル受信/変換,フラッシュ書き換え) + メインプログラムABANK1 = ブートローダーM(Ethernet通信,motファイル受信/変換,フラッシュ書き換え) + メインプログラムB・ ブートローダーLとブートローダーMは同じであっても良いし異なっていても良い・ BANK0で起動した場合は、BANK0のブートローダーLによって、BANK1へブートローダーM + メインプログラムBを両方とも書き込む そして、次回リセット時にBANK1で起動するように起動BANK設定をしておく(FITのAPIであれば、起動バンクをトグル、させておく)・ BANK1で起動した場合は、BANK1のブートローダーMによって、BANK0へブートローダーL + メインプログラムAを両方とも書き込む そして、次回リセット時にBANK0で起動するように起動BANK設定をしておく(FITのAPIであれば、起動バンクをトグル、させておく)
togashiさん、こんにちは。NoMaYです。時系列的に書いた方が良かったかなと思いましたので書いてみました。初期状態:FFE0_0000-FFEF_FFFF: BANK1 = なしFFF0_0000-FFFF_FFFF: BANK0 = ブートローダーL + メインプログラムP↓・ BANK0のブートローダーLによって、BANK1へブートローダーL' + メインプログラムP'を両方とも書き込む・ ブートローダーLとブートローダーL'は同じであっても良いし異なっていても良い・次回リセット時にBANK1で起動するように起動BANK設定をしておく(FITのAPIであれば、起動バンクをトグル、させておく)↓書き込み後:FFE0_0000-FFEF_FFFF: BANK1 = ブートローダーL' + メインプログラムP'FFF0_0000-FFFF_FFFF: BANK0 = ブートローダーL + メインプログラムP↓リセット↓リセット時(リセットベクタリード時)+起動後:FFE0_0000-FFEF_FFFF: BANK0 = ブートローダーL + メインプログラムPFFF0_0000-FFFF_FFFF: BANK1 = ブートローダーL' + メインプログラムP'↓・ BANK1のブートローダーL'によって、BANK0へブートローダーL'' + メインプログラムP''を両方とも書き込む・ ブートローダーL'とブートローダーL''は同じであっても良いし異なっていても良い・次回リセット時にBANK0で起動するように起動BANK設定をしておく(FITのAPIであれば、起動バンクをトグル、させておく)↓書き込み後:FFE0_0000-FFEF_FFFF: BANK0 = ブートローダーL'' + メインプログラムP''FFF0_0000-FFFF_FFFF: BANK1 = ブートローダーL' + メインプログラムP'↓リセット↓リセット時(リセットベクタリード時)+起動後:FFE0_0000-FFEF_FFFF: BANK1 = ブートローダーL' + メインプログラムP'FFF0_0000-FFFF_FFFF: BANK0 = ブートローダーL'' + メインプログラムP''↓以下同様[追記]デュアルモードではブートローダという言葉も似つかわしくなくなりますね。以下のような感じかと思うのです。リニアモードなら、まあ、感覚的にも一致する ⇒ ブートローダー + メインプログラム↑↓デュアルモードは、この言い回しが良いのかも ⇒ プログラム (メインプログラム + ファームウェアアップデートモジュール)
togashiさん、NoMaYさん
シェルティです、こんにちは。
本スレッド内容をまだ詳細まで読み切れてないのですが、フラッシュモジュールの開発チームと相談した結果を持ってきました。引き続き本スレッドをウォッチさせていただきます。
------
[回答]
r_flash_rx 付属のサンプルについては、CS+/e2 studioでエラーが出ないよう改訂を目指します。
またr_flash_rx 付属のデュアルバンクのデモプログラムはバンク切り替えの動作そのものを確認することを想定しております。バンク0、バンク1それぞれ同時にプログラムをダウンロードしているのは、なるべく少ない手順でバンク切り替えの動作を確認できるようにするためであり、デバッグ時のユースケースを想定したものではありません。
適切なファームウェアアップデートの方針は以下アプリノートの考えをベースとして今後展開してまいります。
https://www.renesas.com/us/ja/document/apn/renesas-mcu-firmware-update-design-policy-rev100
以上です
バンク選択機能=バンクスワップ機能=(A)と(B)を切り替えることが出来る機能、というのが適切かなと思うのです。
>数々のご説明ありがとうございます。起動バンクの切り替えをするので、バンク選択機能=バンクスワップ機能となるのですね。私の中でデュアルバンク機能の内容が混在しており、改めてご説明とマニュアルを確認したところ、理解できました。時系列順でのご説明など、大変お手数おかけいたしました。
デュアルモードではブートローダという言葉も似つかわしくなくなりますね。
>こちらに関してもデュアルモードとブートローダーの意味合いも混在してました…。目指しているのはリニアモード(ブートローダー+メインプログラム)に近いイメージです。(まだ概要までしか進んでいませんが、アプリケーションノートの『ブート領域、フラッシュ領域の分割方法』が適しているかと思います。)なので、以前NoMaYさんがご推察されたようにリニアモードが適しているのかと…。
せっかくご説明いただいたデュアルバンク機能を活用できずに申し訳ないのですが、リニアモードで取り組んでみます。
シェルティさん。こんにちは、togashiです。
ご連絡とご回答、ありがとうございます。
詳細中の内容と同じになってしまいすが、デュアルバンクではなくリニアモードでの実行に変更する予定です。
なるべく少ない手順でバンク切り替えの動作を確認できるようにするためであり、デバッグ時のユースケースを想定したものではありません。
>承知いたしました。改訂と今後の展開について、ありがとうございます。
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
リニアモード,デュアルモードのご説明ありがとうございます。設計方針やセキュリティ関連からもデュアルモードが必要になりそうですね…。ファームウェアアップデートに関する情報についても少しチェックしてみます。ご紹介ありがとうございます!