USBホストフラッシュブートローダーについて

はじめまして。よし と申します。

過去の投稿内容やメーカーからご提示されている資料を拝読するものの、どうしても分からないことがありご教示をお願い致します。

現在、RX621でUSBホストフラッシュブートローダーを作ろうとしています。

試しに、アプリケーションノート(R01AN0892JJ0100)とサンプルプログラムを入手しまして、

boot側をサブプロジェクト、download側をメインプロジェクトとして環境を用意しました。

ハードは自作の基板になります。

そこで、いくつか御質問が御座います。

1.boot側の動作としては、起動後、R_Fl_Mode_Entry();へ遷移する事は確認できました。

  当該関数内の以下の処理で、指定アドレスが格納されずif文内へ入ってこず、設定の問題なのかサンプルコードのミスなのか、

  判断が出来ずに迷っております、、、

 

  /* ==== Set target reset vector ==== */
  trgt_vctr_tmp = (uint32_t *)FL_TARGET_REST_VECT_ADDR;

  if(*trgt_vctr_tmp != 0xFFFFFFFFu){
   /* ==== Call user function ==== */
   trgt_fnc = (void (*)())(*trgt_vctr_tmp);
   trgt_fnc();
  }
  else{
   while(1);
  }

  0xFFFFFFFFが格納されており、必ずelseに来てしまいます。

   メモリViewで確認するに、以下となっていました。

  trgt_vctr_tmp = 0xFFFE3FFC

  *trgt_vctr_tmp = 0xFFFFFFFF

 

2.上述の1の状態から、trgt_vctr_tmp = 0xFFFE3FFCとなるように設定をして、

  trgt_fnc()の遷移先を0xFFFE3FFC番地にした際、予期しないアドレスへ遷移してしまいます。

  当方が期待する遷移先は、download側のPowerON_Resetなのですが、TrgtPrgDmmy.cに記載されているTrgtPrgDmmy_mainがコメントアウトされているので、

  ユーザー側で処理を追記する必要があるものなのか、あるいは、download側とのリンクが上手く設定できておらず遷移できていないのか、

  お恥ずかしながらサンプルプログラムにどの様な追加設定・処理をすべきか分からない状態にあります、、、

  関係しそうなノートとして、ブート領域、フラッシュ領域の分割方法(R20UT4547JJ0100)は拝読しております。

 

開発環境は以下になります。

統合開発環境:CS+ for CC V7.00.00 [13 Jun 2018]

CPU:R5F56216B(176pin)

ハード:自作基板

お知恵を貸して頂ける方、どうぞ宜しくお願い致します。

Parents
  • よし さん、こんにちは。NoMaYです。

    NonOS_MscFw_3_.absのMAPファイルを見たところ、以下のTRGT_DMMY_FIXEDVECTセクションが出力されていましたが、これのアドレスが0xFFFE3FFC番地とオーバーラップしていることが原因だと思われます。つまり、ブートローダでダウンロードする場合、このセクションは問題にならない(download.motの内容が上書きされますので正しく0xFFFE3FFC番地に0xFFF80000が書き込まれる)のですが、CS+&E1でdownload.abs+NonOS_MscFw_3_.absをダウンロードした場合、NonOS_MscFw_3_.absの0xFFFE3FFC番地(きっと0xFFFFFFFF)が勝ってしまうのだと思われます。

    NonOS_MscFw_3_.map

    TRGT_DMMY_FIXEDVECT
                                      fffe3fd0  fffe3fff        30   4

    以下のように対策してみてはどうでしょうか?

    (a) NonOS_MscFw_3_.absにTRGT_DMMY_FIXEDVECTセクションが出力されないようにする
    (b) もしかすると、ダウンロード順をNonOS_MscFw_3_.abs→download.absの順にする、だけでも良いかも知れません

Reply
  • よし さん、こんにちは。NoMaYです。

    NonOS_MscFw_3_.absのMAPファイルを見たところ、以下のTRGT_DMMY_FIXEDVECTセクションが出力されていましたが、これのアドレスが0xFFFE3FFC番地とオーバーラップしていることが原因だと思われます。つまり、ブートローダでダウンロードする場合、このセクションは問題にならない(download.motの内容が上書きされますので正しく0xFFFE3FFC番地に0xFFF80000が書き込まれる)のですが、CS+&E1でdownload.abs+NonOS_MscFw_3_.absをダウンロードした場合、NonOS_MscFw_3_.absの0xFFFE3FFC番地(きっと0xFFFFFFFF)が勝ってしまうのだと思われます。

    NonOS_MscFw_3_.map

    TRGT_DMMY_FIXEDVECT
                                      fffe3fd0  fffe3fff        30   4

    以下のように対策してみてはどうでしょうか?

    (a) NonOS_MscFw_3_.absにTRGT_DMMY_FIXEDVECTセクションが出力されないようにする
    (b) もしかすると、ダウンロード順をNonOS_MscFw_3_.abs→download.absの順にする、だけでも良いかも知れません

Children
  • NoMaY 様 ご教示ありがとうございます。

    ご提案頂きました(a)の方法を試してみました。
    単純にsectionを消去してリビルド->ダウンロードを行い、動作確認を行いました。
    意図通り、0xFFF80000のPowerON_Resetへジャンプする事が確認できました。
    ありがとうございます。

    ただ、、、一難去ってまた一難という感じでして、
    0xFFF80000で未定義命令エラーとなり、逆アセンブルすると0xFFF80001以降は?で埋められていました。
    この現象はdownload側の問題ということでしょうか?