AN73854のDual-application Bootloaderについて

[TeMa_2997106]

PSoC4において、AN73854のDual-application Bootloaderを実現している

Code Exampleはありますでしょうか。

CY8CKIT-042など、キット上で動くものがあるとうれしいです。

以上です。

[RyanZhao · Accepted solution]

Matsubara-san,

詳細は添付ファイル「P4_Dual_Image_Bootloader_Demo.zip」をご参照ください。

よろしくお願いいたします。

Ryan Zhao

[TeMa_2997106]

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

いただいたプロジェクトを触ってはいるのですが、現状所望の動作に至っていません。

BootloaderプロジェクトがDual-app bootloader project、各々のBootloadableがInApplicationBootloadable_1/2かと思いますが、これらをどのように管理するのでしょうか。各々のファームウェア(今回であれば1は緑のLEDが点灯、2は赤のLEDが点灯かと思いますが)を、このBootloaderが動的に切り替える処理をするのでしょうか。

オペレーションについてご教示ください。

宜しくお願いします。

[RyanZhao]

Matsubara-san,

お世話になっております。

別の簡単な例（Dual-app bootloader project）が添付されています。

動的に切り替える処理をするのについて、App1/App2 の中,  Bootloadable_Load(); は Bootloader にジャンプするために使用されます、

Bootloaderの中, Bootloader_Exit(uint8 appId); は App1/App2 にジャンプするために使用されます。

* \param appId

*  The application to be started:

*  - Bootloader_EXIT_TO_BTLDR - The Bootloader application will be started on a software reset.

*  - Bootloader_EXIT_TO_BTLDB;

*  - Bootloader_EXIT_TO_BTLDB_1 - Bootloadable application # 1 will be started on a software reset.

*  - Bootloader_EXIT_TO_BTLDB_2 - Bootloadable application # 2 will be started on a software reset. Available only if the "Dual-application" option is enabled in the component customizer.

宜しくお願いします。

Ryan

[TeMa_2997106]

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

新規でプロジェクトの送付もありがとうございます。

こちらのプロジェクトを拝見していますが、通常のフローとしては

- App1/App2のアプリケーションプロジェクトを作成する

　(今回で言うとApp1は緑の、App2は青のLEDを点灯させるアプリケーション)

- 各プロジェクトの.elfと.hexを作成し、各BootloadableコンポーネントのDependenceタブでパスを切る

が基本要素で、ここまではいただいたPDFに記載がありますが、ここからは

- タイマで一定期間カウントすると別アプリの起動&リセットがかかる

という動きになっているかと思います。

トリガがタイマになっているので、これを例えばボタン等にすれば意図したタイミングでの変更が

可能になるかと思いますが、認識間違いないでしょうか。

また、Bootloader_Exitについては今回は触らず、Bootloader_EXIT_TO_BTLDB_2のみを呼んでいますが、

この部分はDual-Applicationの場合はこのままでよい、という認識で間違いないでしょうか。

いまいち全体像がつかみ切れておらず、初歩的な質問で申し訳ありませんが、

宜しくお願い致します。

[RyanZhao]

Matsubara-san,

お世話になっております。

ボタンをトリガーとして使用できます。問題ない。

Bootloader_EXIT_TO_BTLDB_2のみを呼んでいますが、アプリケーションに応じて、別のパラメータ(Bootloader_EXIT_TO_BTLDR，Bootloader_EXIT_TO_BTLDB，Bootloader_EXIT_TO_BTLDB_1，Bootloader_EXIT_TO_BTLDB_2)に変更することができます。

何かありましたら、随時ご連絡のほどよろしくお願い致します。

Thanks,

Ryan

[TeMa_2997106]

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

すみません、もう少し教えてください。

AN73854のp.18、Dual-Application Bootloader Considerationsでは2つのアプリに対して、2つの.cyacdをマージしているような記載がありますが、これはどのように改版すればよいのでしょうか。

このように2面用意しないと、例えばホストからの書き換え途中に電源が落ちるなど不測の事態に陥った際に、ホスト側の再書き込み等のトリガが無い限りPSoCが起動しないことになる可能性があるかと思いますが、認識は正しいでしょうか。

2面あれば、片方の書き換え時にエラーとなっても、もう1面残っているので、そちらをキックすればアプリとしては起動する、というフェイルセーフ機能を実現することができる、と考えています。

今回、フィールドアップデートを想定しており、ホストは常時書き換えできる環境にあるかどうかがわかりません。そんな中、遠隔でPSoCのファームをアップデートする方法を模索している中、このアプリケーションノートにたどり着きました。これが少しの改版で使えるようになるのであれば、リファレンスとして提供したいと考えています。

よろしくご一考ください。

以上です。

[RyanZhao]

Matsubara-san,

いつもお世話になっております。

AN73854のp.18、Dual-Application Bootloader Considerationsでは2つのアプリに対して、2つの.cyacdをマージしているような記載がありますが、これはどのように改版すればよいのでしょうか。

2つの.cyacdをマージすることについて、詳細はCombine Dual-application Bootloadable Hex Files for Production Programming– KBA224390 をご参照ください。

このように2面用意しないと、例えばホストからの書き換え途中に電源が落ちるなど不測の事態に陥った際に、ホスト側の再書き込み等のトリガが無い限りPSoCが起動しないことになる可能性があるかと思いますが、認識は正しいでしょうか。

ご認識は正しいです。

2面あれば、片方の書き換え時にエラーとなっても、もう1面残っているので、そちらをキックすればアプリとしては起動する、というフェイルセーフ機能を実現することができる、と考えています。

確かに。これが、ほとんどの場合Dual-Application Bootloaderが必要な理由です。

ご意見ありがとうございます。

できれば、変更されたプロジェクトは将来、community.cypress.comで更新される可能性がありましよか？

何かありましたら、随時ご連絡のほどよろしくお願い致します。

Thanks,

Ryan

[TeMa_2997106]

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

フローは理解できましたので、試してみます。

マージはコマンドプロンプトで.exeを叩いていますが、これをUlitilyで提供する、

もしくはPSoC Creatorに入れ込むなどの予定はありますでしょうか。

また、「できれば、変更されたプロジェクトは将来、community.cypress.comで更新される可能性がありましよか？」

は、どういう意味でしょうか。マージしたプロジェクトをCDCにアップロードすべき、とおっしゃっていますでしょうか。

(本来であれば、そのプロジェクトをこちらからリクエストしたいのですが)

意図が異なるのであればご指摘ください。

以上です。

[RyanZhao]

Matsubara-san

いつもお世話になっております。

すみません、、、Ulitilyでや、PSoC Creatorに、hex fileのマージツールのスケジュールはありません。

プロジェクトにっいて、コメント（post#6）の意味を誤解しました。私のせいです。。。

プロジェクトのモディファイを完成させることができれば、私はCDCにnew threadで更新します。

Thanks,

Ryan

[TeMa_2997106]

了解しました。

お待ちしてればよいでしょうか。

[TeMa_2997106]

そちらの作業が止まっているかもしれませんので、改めてこちらのリクエストをお伝えします。

AN73854のp.9、Figure7の右図にあるような、2面(+Bootloader)の回路の動作サンプルプロジェクト(動くもの)が欲しいです。

この図のような構成が実現できれば、今回行いたい

1) フィールドアップデート

2) 万が一にアップデート時に書き換え失敗があったとしても古いRevisionを問題なく動作させられる

が実現できます。

現状は、この構成で動くものが無いため、採用に逡巡しています。他ベンダではライブラリを叩けば使用可能なソリューションがあるそうで、使い勝手の時点で(動くものが無い、という意味で)他社の採用を検討しています。

[RyanZhao]

Matsubara-san,

ご返信いただきまして诚にありがとうございます。

プロジェクトの変更は完了しました。これはトリガーとしてGPIOを使用します。

流れ図は以下の通りです。

プロジェクト詳細は添付ファイル「GPIO_Trigger_Dual_Bootlaod.zip」をご参照ください。

In Bootloader project,

Tigger_BTLDR_Start:             

GPIO Pin_1.1 default logic 0, drive mode: Internal Resistive Pull Down. When it tied to VDD(or drive high by host gpio) externally,  goes to wait for host command, if no command received, after Timer timeout(now timeout is 8 seconds periodically), according to status of Trigger_BTLDR_To_APP1 or Trigger_BTLDR_To_APP2, go to APP1 or APP2.

Trigger_BTLDR_To_APP1:    

GPIO Pin_0.0 default logic 0, drive mode: Internal Resistive Pull Down. When it tied to VDD(or drive high by host gpio) externally, goes to APP1.

Trigger_BTLDR_To_APP2:    

GPIO Pin_0.1 default logic 0, drive mode: Internal Resistive Pull Down. When it tied to VDD(or drive high by host gpio) externally, goes to APP2.

In Bootloadable APP1/APP2 project,

Trigger_Go_To_BTLDR:         

GPIO Pin_1.0 default logic 0, drive mode: Internal Resistive Pull Down. When it tied to VDD(or drive high by host gpio) externally, go back to bootloader project.

Note: Do not suggest pulling up more than one gpio mentioned above to VDD(or drive high by host gpio) externally. Otherwise, there may be logic conflict.

よろしくお願いします。

Ryan

[RyanZhao]

外に、PSoC BootloaderまたはBootloadable用のライブラリはありませんが、Bootloader HOST Tool用のライブラリはあります(C:\Program Files (x86)\Cypress\PSoC Creator\4.2\PSoC Creator\cybootloaderutils)。

このライブラは、 HOST MCUまたはPC TOOLSに使用できます。

Thanks,

Ryan

[TeMa_2997106]

RyanZ_36様、

返信が遅れまして失礼しました。

こちらでCY8CKIT-042を使って動作させようとしましたが、意図した動作になりません。

オペレーションは下記です。誤っている場合、Ryan様が行ったオペレーションと異なっている場合は、ご指摘ください。

1) 3つのプロジェクトを各々Buildする

2) Bootloader01をプログラムする

3) Pin1_1, Pin0_0, Pin0_1の順にHighレベルの信号を入力する(VCCとショートさせる)

私が何か根本的なところで間違っていると思うのですが、ヒントがなく、動作させるのに苦慮しています。

以上です。

[RyanZhao]

Matsubara-sama,

申し訳ございません。

まず最初に、Bootloadable1とBootloadable2をマージしてから、CombineHexをPSoC Programmerでプログラムする必要があります。

操作手順：

1) 3つのプロジェクトを各々Buildする

2) Bootloader01をプログラムする  Bootloadable1とBootloadable2をマージしてから、CombineHexをPSoC Programmerでプログラムする

3) Pin1_1, Pin0_0, Pin0_1の順にHighレベルの信号を入力する(VCCとショートさせる)

CombineHex添付資料をご覧ください

Thanks,

Ryan

[TeMa_2997106]

Ryan-san,

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

このオペレーションですとうまくいきました。

ご対応ありがとうございます。

確認ですが、Dual-applicationの場合は.hexのマージがMustなのでしょうか。

この場合、片面だけ書き換えるソリューションとしてはそのまま使うことができない

(常に2面とも書き換えるので)のですが、認識としては正しいでしょうか。

以上です。

[RyanZhao]

Matsubara-san,

いえ、Dual-applicationの場合は.hexのマージがMustなのではありません。

別個方法はbootloadable toolを使用することです：

Thanks,

Ryan

[TeMa_2997106]

Ryan-san,

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

ここでおっしゃっている"bootloadable tool"とは、何を指していますでしょうか。Firmwareでしょうか。

先の図については非常にわかりやすく理解できるのですが、実現の方策についてが、申し訳ないですがまだ私の理解が追い付いていません。

以上です。

[RyanZhao]

Matsubara-san,

ご迷惑をおかけしました。

上記の"bootloader tool"は"Bootloader Host"です。　

PSoC Creator Menu -> Tools -> Bootloader Host. ご参考まで。

Thanks,

Ryan

[TeMa_2997106]

Bootloader Hostはユーティリティの形でしか提供は無いでしょうか。

実際の運用上では、Hostにあたるもの(例えば別のMCUや、可能であればPSoC自身がHostとなる)が制御する形を採りたいです。

書き換え毎にPSoC Creatorを必要とするのであれば、現実的ではないです。

Bootloader Hostの原理はどのようなものでしょうか。アドレスで区切っているのでしょうか。

例えば、App1とApp2を書き換えた後、App2のみをアップデートしたい、という場合には

App2のスタートアドレスを誰がどのように解釈するのでしょうか。

[RyanZhao]

Matsubara-san,

Bootloader HOST のライブラリはあります(C:\Program Files (x86)\Cypress\PSoC Creator\4.2\PSoC Creator\cybootloaderutils)。

このライブラは、 HOST MCUまたはPC TOOLSに使用できます。

MCU Bootloader HOST 例：https://www.cypress.com/documentation/application-notes/an86526-psoc-4-i2c-bootloader

cm0gcc.ldなファイルでは、App1とApp2の開始アドレスと終了アドレスが定義されています。

App1とApp2のフラッシュサイズは同じです。

以上です。

Best Regards,

Ryan

[TeMa_2997106]

ありがとうございます。方式については理解できました。

いただいた情報で試してみます。