RX65N USBマスストレージ経由内蔵FlashROM書き換えプログラム書き換えについて

USBマスストレージ経由内蔵FlashROM書き換えプログラム(R01AN3503JJ0105)をRX65N(R5F565N9BxFB)搭載の独自ボードにて実現しようとしています。
開発環境はCS+ for CC V8.1.0.00、E1を使っています。

USBメモリからユーザープログラムは取り込みできており、書き換えまでは完了していそう(LEDの点滅状態から推測)なのですが、以下のErase処理を完了した次の命令で在らぬアドレスへ遷移してしまいます。LEDはLED_A、LED_Bの2つに集約しており点灯、点滅、消灯にてベースのサンプルコードを元にインジケートを変更しました。

バックアップ機能を有効としており、ユーザー側のUserApp_Head_Sectを0xFFF80000に設定(main.cへの追記、セクションの追加)、セキュリティコードも仕様書に則って合わせました。
オプション設定が含まれるとエラーになる。と仕様書に記載があったので、motファイルは分割出力をしています。
出力ファイル1は、FE7F5D00-FE7F5D7Fの範囲(オプション設定)、出力ファイル2はFFF00000-FFFFFFFFの範囲(CPU型番のメモリマップからプログラム領域を指定)


この条件にてUSBメモリを挿入して書き換え処理を進めますと、fu_copyarea()で想定しないアドレスへ遷移してしまいます。
この原因を究明しているのですが、お力添えを頂きたくお願いいたします。

 

[LEDの状態遷移仕様]

起動時:両方のLEDが点灯
USBメモリ接続待ち:LED_Aが点滅、LED_Bは点灯
Erase中:両方のLEDが消灯
書き換え中:LED_A、LED_Bが交互に点灯/消灯
エラー状態:LED_Aが点灯、LED_Bは点滅

[現象]

LED仕様に準じて遷移しておりエラー状態にはなっていない。
書き換え中のLED状態が完了した後、以下の関数を処理しようと遷移します。
その際、破綻するコードが以下の中であることまではE1接続にて確認できています。

r_fwupdater_apl.c 541行目:fu_copyarea()
       ↓
r_fwupdater_apl.c 335行目:fl_rom_erase()
       ↓
r_flash_apl.c    217行目:fl_erase_processing()
       ↓
r_flash_apl.c    257行目:R_FALSH_Erase()
 →r_flash_rx.c    180行目:r_flash_erase()
 →r_flash_groupe.c  431行目:r_flash_erase()

R_FALSH_Erase()内の2つの関数から正常にて戻り、R_FALSH_Erase()の次の命令を実行するところでisr_dummy_isr()へ遷移してしまう。
なので、eraseした結果、プログラムコードを見失ったという印象。

[疑問点]
・r_fwupdater_apl.c 335行目:fl_rom_erase()で引数として渡されるerase_end_addrは、
 直前のerase_end_addr = FU_FWUPDATER_START_ADDRESS - 1;で設定されているのですが、書き換えプログラムの保存番地まで壊さないものでしょうか?

・E1でステップ実行していることがそもそもの要因と考えられますでしょうか?
 予め読み込んだプログラムをアドレス展開しているはずなので、動的に書き換えられたプログラムまでリアルタイムで展開できないのではないか。

・仕様書には「フラッシュ P/E プロテクトレジスタ」の設定が書かれていないのですが、デフォルトではプログラム/イレース、ブランクチェックは禁止なので、
 この設定をどこかで有効にしておく必要はないものでしょうか?

ご多忙のところ大変恐縮ですがご指導をお願いいたします。

Parents
  • 疑問点の1つにつきまして問題ないことが確認できました。

    ・r_fwupdater_apl.c 335行目:fl_rom_erase()で引数として渡されるerase_end_addrは、
     直前のerase_end_addr = FU_FWUPDATER_START_ADDRESS - 1;で設定されているのですが、書き換えプログラムの保存番地まで壊さないものでしょうか?

     ⇒erase_start_addr = 0xFFF80000
           erase_end_addr  = 0xFFFF7FFF

    USBマスストレージ経由内蔵FlashROM書き換えプログラム配置領域は0xFFFF8000 - 0xFFFFFFFFなので、書き換えプログラムの番地までは壊さないことがわかりました。

    他の2点の懸念点については引き続き調査中である為、アドバイスが御座いましたらお願いいたします!

Reply
  • 疑問点の1つにつきまして問題ないことが確認できました。

    ・r_fwupdater_apl.c 335行目:fl_rom_erase()で引数として渡されるerase_end_addrは、
     直前のerase_end_addr = FU_FWUPDATER_START_ADDRESS - 1;で設定されているのですが、書き換えプログラムの保存番地まで壊さないものでしょうか?

     ⇒erase_start_addr = 0xFFF80000
           erase_end_addr  = 0xFFFF7FFF

    USBマスストレージ経由内蔵FlashROM書き換えプログラム配置領域は0xFFFF8000 - 0xFFFFFFFFなので、書き換えプログラムの番地までは壊さないことがわかりました。

    他の2点の懸念点については引き続き調査中である為、アドバイスが御座いましたらお願いいたします!

Children
  • 残りの疑問点の2つにつきまして問題ないことが確認できました。

    ・E1でステップ実行していることがそもそもの要因と考えられますでしょうか?
     予め読み込んだプログラムをアドレス展開しているはずなので、動的に書き換えられたプログラムまでリアルタイムで展開できないのではないか。

    ⇒書き換え完了後は、リセットベクタへ遷移し、再度書き換え処理のフローになる為、
     ユーザーアプリケーションプログラムへの遷移ではありませんでした。
     その為、SW状態をはじめ、書き換え処理へ移行する条件のままですと繰り返し何度も書き換え実行されています。
     これはその様な仕様となっていますので問題では御座いません。

    ・仕様書には「フラッシュ P/E プロテクトレジスタ」の設定が書かれていないのですが、デフォルトではプログラム/イレース、ブランクチェックは禁止なので、
     この設定をどこかで有効にしておく必要はないものでしょうか?

    ⇒こちらもE1接続状態であれば意識する必要はありませんでした。
     他のBoot接続で書き換えする場合は、仕様書に記載のBootピンに関わる設定を施して書き換えすれば問題無い物と思います。

    これにて本質問はCloseといたします。