ブロック単位でのみ消去できるフラッシュを使用して増分更新を実行するにはどうすればよいですか？

シナリオ

低コストのIoTデバイスを無線でデバイスのマイクロコントローラーを更新する新しいファームウェアで更新したい。マイクロコントローラのメモリは、32kから128kの範囲（セントカウント単位）のフラッシュメモリです。この安価なメモリには1つの大きな制限があります。ブロック単位でしか消去できません。

質問

これは、差分（デルタ）更新を実行できないことを意味しますか？コントローラのメモリ全体（または少なくとも重要な部分）を常に更新する必要がありますか？

すべてをフラッシュする必要性を減らし、デバイスを完全にブリックするリスクをできるだけ減らしたいと思います。マイクロコントローラーを無線でフラッシュする場合の既存の戦略はありますか？

単純な答えは「はい」です。高い信頼性が必要な場合は、ブートローダーとA / Bコードイメージをサポートするのに十分なフラッシュブロックが必要です。新しいイメージをアクティブ化する前に、すべてを書き込んで確認し、場合によっては再試行できます。

ただし、これは高価で信頼性の高い戦略であり、オーバーヘッドを削減するためにできることがいくつかあります。OTA更新の低レベルのサポートは、デバイスのファームウェアまたはOSの一部としても提供される可能性があるため、学習したくない場合は、独自のローリングを回避できます。この機能はと記述される場合がありFOTAます。

コードベースを分割すると、増分更新が可能になります。ブートローダーがフォールバックユーザーコードを必要とせずにネットワーク接続を起動し、コードをダウンロードして検証できるのが最良の場合です。ローカルゲートウェイを使用すると、このタスクの管理を低コストのエンドポイントから委任できます。

多くのデバイスには少量のワード消去フラッシュがあり、これが失敗しても、通常はブロック全体を消去する必要なくビットを設定できます。これらの機能を使用して、ジャンプテーブルを操作し、ブロックサイズのチャンクで更新されるコードをつなぎ合わせることができます。最初に完全なA / Bコードスペースを計画した場合でも、コードベースが大きくなりすぎると、より複雑なスキームにフォールバックする必要がある場合があります。

洗練されたファームウェアオーバーザエアソリューションで実現できる機能を明確にするために、残りのユーザーアプリケーションスペース全体が再フラッシュされる間、ブートローダーと潜在的にプライマリ通信スタックを常駐させることができます。これはオーバーヘッドを必要としません（特にブロック分割がソフトの場合）。通信スタックをアップグレードする必要があるシナリオでは、アプリケーションコードに一般的に使用される領域を、ダウンロードおよび検証中に一時的に使用できます。これを実現するにはSoCでのサポートが必要ですが、これを念頭に置いて設計された第2および第3世代のデバイスはすでに存在しています。

すべてをフラッシュする必要性を減らし、デバイスを完全にブリックするリスクをできるだけ減らしたいと思います。マイクロコントローラーを無線でフラッシュする場合の既存の戦略はありますか？

比較的静的な更新を行うコードとは別に、アクティブイメージとバックアップイメージの2つのイメージをストレージに保持する必要があります。更新する必要があるときはいつでも、バックアップで更新してから、アクティブに切り替えます。安定したら、バックアップになるはずの古いアクティブなイメージを更新します。

これを念頭に置いて、両方の画像を更新するときにウェアレベリングアルゴリズムを使用できます。このようなアルゴリズムのコードは、総ストレージの約10〜15％を占める可能性がありますが、デバイスの寿命を延ばすのに十分価値があります。

ウェアレベリングは通常、フラッシュコントローラによって管理されます。フラッシュコントローラはウェアレベリングアルゴリズムを使用して、データがプログラムされるたびに使用する物理ブロックを決定します。ソリッドステートドライブ（SSD）のウェアレベリングには、動的と静的の2つのタイプがあります。動的ウェアレベリングは、消去されたブロックをプールし、次の書き込みのために消去カウントが最も低いブロックを選択します。

一方、静的ウェアレベリングでは、全体的な消去回数が最も少ないターゲットブロックを選択し、必要に応じてブロックを消去し、新しいデータをブロックに書き込みます。ブロック消去回数がa未満の場合は、静的データのブロックを確実に移動します。特定のしきい値。データを移動するこの追加の手順では、フラッシュコントローラーのオーバーヘッドが原因で書き込みパフォーマンスが低下する可能性がありますが、スタティックウェアレベリングは、ソリッドステートデバイスの寿命を延ばすためにダイナミックウェアレベリングよりもはるかに効果的です。

（Techtarget.com：ウェアレベリング）

フリースケールセミコンダクターは、Kinetisマイクロコントローラー用の無線ファームウェアアップグレードの堅牢な方法について説明しています。

プログラムフラッシュメモリスワップと呼ばれます。

フラッシュメモリスワップを使用するシステム

スワップをサポートする2つ以上の内部フラッシュブロックを備えたデバイスでは、各フラッシュブロックのメモリベースアドレスを交換できます。したがって、各フラッシュブロックのアドレス位置は、デバイスの論理メモリマップでスワップされます。リセット後、組み込みのフラッシュスワップシステムは基本的に、論理メモリマップ内のフラッシュブロックの位置によって実行するソフトウェアを選択します。これにより、プログラミングがさらに容易なコードバックアップシステムが可能になります。他のブロックを消去/プログラミングしながら、1つのブロックから実行できます。Kinetisデバイスでは、フラッシュスワップシステムが古いアプリケーションから新しいアプリケーションへの切り替えのすべてのステップを監視/制御します。これらのステップの1つで停電が発生した場合でも、信頼性の高い動作が保証されます。

メリット

• プログラミングのしやすさ。アプリケーションは常にメモリマップの下位ブロックから実行されます。
• 耐電力損失。
• ブートローダーは必要ありません。メインアプリケーションの開始に遅延はありません。
• マルチタスクOSに最適です。アプリケーションのダウンタイムを最小限に抑えます。マルチタスクシステムでは、アプリケーションの新しいコピーを更新するためにバックグラウンドタスクが実行されている間、メインアプリケーションタスクを実行し続けることが可能です。
• コードのバックアップコピー。既知の動作中のアプリケーションに戻すことが可能です。

短所

• バックアップコピーを保存するために必要な追加のフラッシュメモリスペース。

ブロックを更新してから、それらを交換できます。

リンクされたドキュメントには詳細な説明が含まれています。

それはより安全なファームウェアのアップグレードを保証しますが、より多くのフラッシュメモリを必要とするので、確かにより多くのコストがかかります。また、どのタイプのマイクロコントローラーにも適用できません。内部フラッシュブロックのスワップをサポートするマイクロコントローラーのみです。