Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

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)

ハード:自作基板

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

  • よし さん、こんにちは。NoMaYと申します。

    アプリケーションノートR01AN0892JJ0100を見てみたところ以下の記載がありますしたので、以下の(1)と(2)の可能性が高く、しかしどちらもOKであるなら、(3)についてデバッグすることになるかな、と私は思いました。(すみません、まだ私は、サンプルプログラムはダウンロードしていなくて、ドキュメントのみ見てみた範囲でのこと、ですが。)

    (1) そもそもdownload側をブートローダでダウンロードしていない
    → これは、よしさんが、したか/しなかったか、ですので直ぐに分かると思います

    (2) download側のプロジェクトのセクション設定に誤りがあってFL_TARGET_REST_VECT_ADDRにdownload側のPowerON_Resetルーチンのアドレスが格納されていない
    → download側のMOTファイルに、FL_TARGET_REST_VECT_ADDR番地にPowerON_Reset番地の値がレコードとして出力されているかどうかですので、エディタで調べれば分かると思います。(MOTファイルの仕様に関してはアプリケーションノートにも記載があります。)

    (3) ブートローダが正常動作しておらず、USBメモリ内のMOTファイルの内容を正しくRX621のフラッシュメモリに書き込めていない。
    → 上記の(1)と(2)がOKであるなら、もうそういうことになってしまうと思いますので、後は地道にデバッグしていくのみかな、と思います。

    R01AN0892JJ0100

    ドキュメント
    www.renesas.com/jp/ja/doc/products/mpumcu/apn/rx/001/r01an0892jj0100_rx62n_621.pdf

    ダウンロード
    www.renesas.com/jp/ja/software/D3007834.html

    ドキュメントの画面コピー


     

  • In reply to NoMaY:

    NoMaY 様 ご指摘ありがとうございます。

    頂いた項目を一つずつ確認して参りました。
    >>(1) そもそもdownload側をブートローダでダウンロードしていない
      ->ブートローダーではダウンロードしておりません。
      download側をメインプロジェクト、boot側をサブプロジェクトにして、E1でデバッグを開始していました。
      どちらのプロジェクトも設定が正しければ、boot側からdownload側へジャンプして、
      download側のリセットベクタへ遷移するものと思っていました。
      つまり、配置アドレスがオーバーラップしていなければ、両方のプロジェクトのプログラムが展開されて、
      然るべき動作になるのだと解釈しておりました。
      ちなみに、両方のプロジェクトはダウンロードした後、HEW->CS+への変換を掛けただけになります。

    >>(2) download側のプロジェクトのセクション設定に誤りがあってFL_TARGET_REST_VECT_ADDRに
      download側の PowerON_Resetルーチンのアドレスが格納されていない
      ->こちらはご指摘の通りでした。
       download側のmotファイルには、0xFFFE3FFC番地が出力されていませんでした。

    この時点で(3)に及ばずとも、見直しをする点がいくつか存在するのですが、download側のvecttbl.cには、
    #pragma section C FIXEDVECTで割り付け処理が掛かれてありました。
    このFIXEDVECTは0x0FFFE3FD0番地に開始セクション設定がされています。
    続いて、vecttbl.c内にはDummyも含めまして12個のVector dataが掛かれており、PowerON_Resetは丁度、0xFFFE3FFCに位置する箇所に存在しています。

    ところが、実際のPowerON_Resetが配置されるアドレスは、resetprg.cで#pragma section ResetPRGとなっているので、0xFFF80000番地に設定されます。

    正に、ここが当方の知見が及んでいない部分だと認識しておりまして、vecttbl.cの記載された処理は、添付頂いたドキュメントの画面コピーにある、「0xFFFE3FFC番地に書かれたアドレスを実行」に相当するものではないのでしょうか?
    FIXEDVECTセクションの0xFFFE3FFC番地にPowerON_Resetのジャンプ先があり、実際のPowerON_Resetの配置番地である、0xFFF80000番地へジャンプする・・・と解釈したのですが、ご指摘頂いた通り出力コードはその様になっていないので、認識が間違っていることは理解ができております。

    初心者の質問で申し訳ございません、、、
  • よし さん、こんにちは。NoMaYです。

    >正に、ここが当方の知見が及んでいない部分だと認識しておりまして、vecttbl.cの記載された処理は、添付頂いたドキュメントの画面コピーにある、「0xFFFE3FFC番地に書かれたアドレスを実行」に相当するものではないのでしょうか?

    言われてみると、確かに1つ目の画面コピーの図の部分だけ見ると、よしさんが予想しているように(でもそれは文章の表現とは違うようですが)解釈してしまうのも無理ないですね。でも、以下であることをお伝えすれば、画面コピーの文章の部分から図の真の意味を解釈し直せるかも知れないかな、と思いました。

    「0xFFFE3FFC番地に書かれたアドレスを実行」≠「0xFFFE3FFC番地を実行」

    「0xFFFE3FFC番地に書かれたアドレスを実行」=「『0xFFFE3FFC番地に書かれたアドレス』を実行」=「0xFFF80000番地を実行」

    また、C言語で書けば以下のようになることもお伝えすれば、理解の助けになるかな、と思いました。(赤字の部分が異なります。)

    「0xFFFE3FFC番地を実行」(trgt_vctr_tmp = 0xFFFE3FFC として)
     trgt_fnc = (void (*)())trgt_vctr_tmp;
     trgt_fnc();

    「0xFFFE3FFC番地に書かれたアドレスを実行」(trgt_vctr_tmp = 0xFFFE3FFC かつ *trgt_vctr_tmp = 0xFFF80000 として)
     trgt_fnc = (void (*)())(*trgt_vctr_tmp);
     trgt_fnc();

    ちなみに、以下ですが(最初の文章もそうですが)、文章の表現とよしさんが言いたいことが合っていない気がします。文章の表現としては、正に、出力コードはその様になってますよ。これは、こう書かないと他の人には伝わらないのではないか、と思うのです。

    >FIXEDVECTセクションの0xFFFE3FFC番地にPowerON_Resetのジャンプ先があり、実際のPowerON_Resetの配置番地である、0xFFF80000番地へジャンプする・・・と解釈したのですが、ご指摘頂いた通り出力コードはその様になっていないので、認識が間違っていることは理解ができております。

    よしさんが言いたかったであろうこと:

    0xFFFE3FFC番地にPowerON_Resetのジャンプ先があり
    ⇒ 0xFFFE3FFC番地にPowerON_Resetへジャンプするジャンプ命令があり

    それで、頂いたリプライ全体から推測すると、(2)に関してはOKで、でも(1)に関して認識の間違いがあるように思われます。

    >つまり、配置アドレスがオーバーラップしていなければ、両方のプロジェクトのプログラムが展開されて、然るべき動作になるのだと解釈しておりました。

    両方のプログラムが、CS+&E1でダウンロードされる訳では無い、です。CS+には、アクティブプロジェクトという概念があり、アクティブプロジェクトとなっている方だけしか、CS+&E1でダウンロードされないですよ。(現状はboot側のサブプロジェクトがアクティブプロジェクトになっているのではないでしょうか?)

    もしかすると、手作業で、順に両方CS+&E1でダウンロードしているかも知れませんが、CS+のデフォルトは、私の記憶では、新しいプログラムをダウンロードする時には古いプログラムを消す(新しいプログラムでコードが無い部分は強制的に0xFFになる)ようにダウンロードされる、という動作だったと思います。(つまり、仮に、メインプロジェクト(download)側→サブプロジェクト(boot)側の順に手作業でダウンロードしていたとしても、結局、メインプロジェクト(download)側は消されてしまい(0xFFになってしまい)、サブプロジェクト側(boot)しかダウンロードしなかったことと同じになります。)

    よしさんが期待しているようにダウンロードするには、アクティブプロジェクト(現状はboot側のサブプロジェクトがアクティブプロジェクトになっているのではないでしょうか?)の方のデバッガのプロパティ設定で、メインプロジェクトとサブプロジェクトの.ABSファイルを共に(2つとも)ダウンロードするように設定しないといけない筈だと思います。

  • In reply to NoMaY:

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

    文章表現が分かりづらく、申し訳ございません。
    整理できていない知識を文章にしている部分もあり、混沌としている表現になっていると思います、、、

    また、私が申し上げたかったことを代弁頂きありがとうございます。
    意図は記述頂いた内容の通りになります。

    以下はサンプルプログラムそのままの状態だと思われ、*trgt_vctr_tmp = 0xFFF80000になっていないのが、当方の現状です。

    >> 「0xFFFE3FFC番地に書かれたアドレスを実行」
    >> (trgt_vctr_tmp = 0xFFFE3FFC かつ *trgt_vctr_tmp = 0xFFF80000 として)

    >> trgt_fnc = (void (*)())(*trgt_vctr_tmp);
    >> trgt_fnc();



    trgt_vctr_tmp = 0xFFFE3FFCは、FL_TARGET_REST_VECT_ADDRに0xFFFE3FFCが格納されており、直前行で代入されている事から問題無いと認識しております。
    *trgt_vctr_tmp = 0xFFF80000が期待する値であるが、*trgt_vctr_tmp = 0xFFFFFFFになっており、上手く設定が出来てないと感じていました。

    CS+&E1を使う場合、サブプロジェクト->メインプロジェクトの順に処理がされると理解しております。
    また、E1では、download側の「デバッグツール」->「ダウンロード・ファイル設定」の「ダウンロードするファイル」項目にdownload.abs(download側のモジュールファイル)とNonOS_MscFw.abs(boot側のモジュールファイル)を追加しています。

    試しに、download側(メインプロジェクト)のダウンロードファイルを1つだけに戻して、サブプロジェクトであるboot側に両方のダウンロードファイルの設定をしてみましたが、起動後にリセットベクタに来ず、CS+が実行状態のまま操作できなくなってしまいました。

    ここは、R20UT4547JJ0100の「5.デバッグツール」に設定方法が書かれておりましたので、そのまま抜粋処理しました。

    *trgt_vctr_tmp = 0xFFF80000とする為に、補完すべき設定や処理を模索していますが、
    何が不足しているのか及んでおりません、、、
  • よし さん、こんにちは。NoMaYです。

    >また、E1では、download側の「デバッグツール」->「ダウンロード・ファイル設定」の「ダウンロードするファイル」項目にdownload.abs(download側のモジュールファイル)とNonOS_MscFw.abs(boot側のモジュールファイル)を追加しています。
    >試しに、download側(メインプロジェクト)のダウンロードファイルを1つだけに戻して、サブプロジェクトであるboot側に両方のダウンロードファイルの設定をしてみましたが、起動後にリセットベクタに来ず、CS+が実行状態のまま操作できなくなってしまいました。

    そうなりますと、アクティブプロジェクトはdownload側(メインプロジェクト)になっていて、そのアクティブプロジェクトでdownload.abs(download側のモジュールファイル)とNonOS_MscFw.abs(boot側のモジュールファイル)をダウンロードするようになっていて、問題無さそうですね。

    では、次は、download.absとNonOS_MscFw.absのMAPファイルをzipファイルに固めたものを添付してリプライして頂けないでしょうか?

    また、それで私の方で分からなければ、その次はdownload.absとNonOS_MscFw.absそのものをzipファイルに固めたものを添付してリプライして頂くことをお願いすることになるかと思います。それをシミュレータにダウンロードして、どうダウンロードされるのか調べてみようと思います。

    ここまで頂いたリプライで、以下の(A)はOKそうですので、(B)の原因を探ることになります。

    (A) download.absの0xFFFE3FFC番地には0xFFF80000が格納されている
    (B) でもCS+&E1でdownload.abs+NonOS_MscFw.absをダウンロードした時にRX621の0xFFFE3FFC番地が0xFFFFFFFFFになっている

  • In reply to NoMaY:

    NoMaY 様 ご返信ありがとうございます。

    お忙しい中、ご対応頂きありがとうございます。

    両方のプロジェクトのabsファイル、mapファイルをzipにしました。

    一度、ご確認をお願い致します。

    abs_mapファイル.zip

  • よし さん、こんにちは。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の順にする、だけでも良いかも知れません

  • In reply to NoMaY:

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

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

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

    >逆アセンブルすると0xFFF80001以降は?で埋められていました。

    念の為、逆アセンブルウィンドウが表示されているCS+の画面コピーを見せて頂けませんか?

  • In reply to NoMaY:

    NoMaY 様 お手数をお掛けしております。

    スタックはデフォルト設定のままになっています。

    SU、SI共に倍に設定してみましたが、特に変化はありませんでした。

     

    download側の逆アセンブル画像

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

    あっ、、、R5F56216B(176pin)ってROM256KB品ではないですか?

  • In reply to NoMaY:

    NoMaY 様 すみません、、、

    これは初歩的ミスですね。
    PowerON_Resetのジャンプ先アドレスが正しくありませんでした。
    256Kの番地である0xFFFC0000に設定することで問題ありませんでした。

    長らくご指導頂きましてありがとうございました。
    大変勉強させて頂きました。

    今回は前段階として、サンプルプログラムでの動作検証を進めていましたが、
    この後、USBアップデートでのプログラム書き換えを確認しまして、
    随時、download側をこちらの製品プログラムへ変更していく予定です。

    それにしても、自分の理解力や知識の中で、伝えたい事を文章にしたり表現するのは、難しいですね、、、

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page