組み込みデバイスのソフトウェアをアップグレードすると、多くの場合、デバイスが「ブリック」する可能性があります。たとえば、ソフトウェアを FLASH に書き込んでいる最中に電源が落ちた場合などです。2 つの質問:
それはすべて、アプリケーションの重要度に依存します。2 つの基本的なアプローチ (バックアップとブートローダー) が組み合わされることもあります。
多くのシステムには、読み取り専用のブートローダー ( redboot など) と、2 つのバンクのフラッシュ メモリ (ほとんどの場合、同じチップ上) があります。ブートローダには、ブートするバンクを選択するためのフラグがあります。フラグは、アップグレード (失敗または成功) などのイベントに基づいて変更されます。
そのため、アップグレード時に、実行中のバージョンは新しいロードをバックアップ バンクにコピーし、チェックサムをチェックし、ブート フラグを切り替えてから、デバイスを再起動します。デバイスは、新しい負荷で新しいバンクで再起動します。再起動後、新しいロードは自身をバックアップ バンクにコピーできます。
多くの場合、ハードウェア リセット付きのウォッチドッグ タイマーもあります。このようにして、ファームウェアが異常になった場合、ウォッチドッグのキックに失敗し、ハードウェアのリセットによってデバイスが再起動され、ブートローダーが正常なロードを探します。
Open Mesh プロジェクトは、このアプローチの良い例です。
チェックサムは優れていますが、破損したデータのフラッシュからあなたを救うだけです. 有効なチェックサムを持つイメージ ファイルをフラッシュしても、製品モデルが異なる場合はどうなるでしょうか。緊急の破損の場合にアクセスできる読み取り専用のデフォルトのブートローダーは、私が見た中で最高のものです.
内部フラッシュのチェックサム。CRC/チェックサムが機能しない場合のデフォルトのバックアップ。このようにして、デバイスが不正確なチェックサムを取得した場合、アップグレードが不完全であることを認識し、別のデバイスに保存されているデフォルト/以前のファームウェアにリセットできます。
これには、チェックサムをチェックするために、起動前 (おそらくブートローダー内) が必要です。コードの静的ビット。
edit : 他の場所のコメントへ。破損したファームウェアだけでなく、間違ったファームウェアをチェックしたい場合は、checsum/checkdata でバージョン情報もカプセル化できます (およびそのヘッダーのチェック)。
私の経験では、デバイスに必要な 2 倍のコード/データ スペースを確保する余裕があり、再起動できる場合は、コスト ポイントが何であるかに帰着します。簡単で、すべての余分なスペースに新しいバージョンを保存し、適切に実行してください。新しいイメージのチェックサム チェック。また、そうしないとなりすましの可能性があるため、新しいファームウェア イメージをより深くチェックすることをお勧めします。たとえば、新しいイメージの出所を保証するある種の暗号化キーなどです。たとえば、PIC を使用するあるプロジェクトでは、新しいファームウェア イメージ用の外部 EEPROM と、ブート時に設定すると EEPROM から新しいイメージをロードするフラグがありました。
運が悪ければ、つまりそのスペースを買う余裕がない場合、人生はより面白くなり、更新中の失敗の可能性を完全に回避する保証された方法はおそらくありません。すべての場合において、ブートローダーは書き込み保護されたメモリの一部にある必要があり、スペースに余裕がある場合は、外部接続の基本的な形式が必要です。ブートローダーに非常に単純な USB ドライバーを使用するシステムと、非常に単純な UDP を使用するシステムを実行しました。ネットワークスタックのみ。どちらの方法でも、更新中に障害が発生した場合に、少なくともデバイスに新しいイメージを取得できます。このような場合、ブートローダーを読み取り専用メモリ領域に配置することを強くお勧めします。更新する機能は失われますが、ヘイワイヤーの更新によってデバイスが完全にブリック状態になることはありません。
最後の可能性は、実行中にコードの一部を更新する必要があるシステムです...これは非常にトリッキーであり、通常、メモリ内の関数の場所を複雑に制御し、達成するためにメモリレイアウトで事前に主要な計画を立てる必要があります。それは楽しいことではありませんが、実行可能です。
両方の質問に答えるには、特定のハードウェア リソースに関係なく、次のようにします。
アプリケーション コードを実行する前 (起動時またはダウンロードの完了後) に、ブートローダーがアプリケーションの CRC チェックを行うようにしてください。有効でない場合、ブートローダーはコードを実行しません。
ブートローダがアプリケーション コードを実行できないと判断した場合、これをユーザーに通知し、ダウンロードを再開する機能が必要です。
プロセッサにバックアップ アプリケーションを保存するための十分なフラッシュがない場合、またはダウンロードが完了するまで新しいアプリケーションを保存するための RAM が不足している場合、これらは明らかにより重要になります。
このような場合、ダウンロードするファイルに小さなヘッダーを付けて、ブートローダーがそのファイルがシステムに適していると判断できるようにすることは理にかなっています。このヘッダーには CRC も含まれる場合があります。ヘッダーがこのシステムに対して有効で、CRC が正しい場合、ブートローダーはフラッシュを消去し (それ自体は消去できません!)、ダウンロードを続行できます。そうでない場合は、既存のアプリケーション コードに触れることなく中止します。
このQに答えられることは知っていますが、信頼性を高める必要がある人もいます。プロジェクトが本当にミッションクリティカルである場合は、このルートに進むことができます。
基本的な計画は、失敗することのないバックアップ計画を常に用意することです。
実際のプロセッサのフラッシュメモリをプログラムできるPICまたは他のマイクロコントローラがあります。データのブロックでチェックサムを使用し、シリアル、USB、またはイーサネットを介してインターフェースします（笑わないでください）このデバイスはフィールドで（またはおそらくこれまで）再プログラムできないため、常にバックアップ計画。PICはPPP/SLIPまたはehternetを介してWebサーバーを実行できるため、PICとのインターフェースは必ずしも厄介ではありません。GoogleTCP-リーン。ぐちゃぐちゃにしないようにしてください。（サイト は仕事に適しています）。プログラミングポートを別の場所に配置します。セキュリティは保証されていません。
プログラムはメインCPUで実行され、独自のブートローダーを実行します。ブートローダー、メンテナンスプログラム、および実際のプログラムの3つのプログラムがあります。
これにより、プログラムだけでなく、ブートリーダープロセスへのアップグレードも可能になります。バックアップブートローダーを追加のフラッシュで実行できます。ウォッチドッグを使用してリセットし、起動しない場合はバックアップを使用します。
つまり、アップグレード可能な組み込みアプリケーション、アップグレード可能なブートローダー、およびアップグレード可能なメンテナンスモードがあります。そして、失敗することのないバックアップモード。
誰もこれが役に立つと思う必要がないことを願っています。