GSMモデムを搭載したARMボードを作成します。
ARMファームウェアを無線でアップグレードできるようにしたいと考えています。
そのための良い、信頼できる、オープンソースのソリューションはありますか?
そうでない場合、この機能を備えた有料OSはありますか?
GSMモデムを搭載したARMボードを作成します。
ARMファームウェアを無線でアップグレードできるようにしたいと考えています。
そのための良い、信頼できる、オープンソースのソリューションはありますか?
そうでない場合、この機能を備えた有料OSはありますか?
回答:
既成のソリューションについては知りませんが、1つのプロジェクトでどのように対処したかを説明します。完全に「ブリックできない」というわけではありませんが、何千ものアップグレードが失敗することは知りません。このアプリケーションでは、非常に低い故障率でも、ユニットにアクセスする必要がある場合よりも安くなります。
メインアプリケーションには、通常の通信プロトコルに3つの追加パケットタイプが追加されています。これには、エラー検出と再試行ステートが含まれます。
begin firmware updateコマンドは、外部SPIフラッシュの予約済みメモリ領域をクリアします。ユニットがバックアップバッテリーから実行されている場合、または外部電源から実行されているがバッテリーの充電状態が25%未満の場合は、エラーを返します。
ブロック書き込みコマンドは、外部フラッシュメモリに小さなチャンクで書き込まれるオフセットアドレスとデータを受け入れます。上位レベルのプロトコルは、エラー検出と再送信を処理します。各ブロックが書き込まれた後、コマンドが確認される前に読み戻されて検証されます。
ファームウェア更新の終了コマンドには、受信したファームウェアがさらに検証するためにイメージ全体のCRC32と一緒に存在する必要がある長さが含まれています。それが外部フラッシュメモリの内容と一致し、電源状態がまだOKの場合、同じ長さでCRC32が「マジックナンバー」とともにEEPROM領域に転送され、ファームウェアの更新が保留中であることを示します。
メインアプリケーションでハードループが実行され、ウォッチドッグが強制的に再起動されます。
ブートローダー(ARMのフラッシュの書き込み保護された領域にあります)は、EEPROM内のマジックナンバーを確認し、イメージのCRC32をもう一度確認します。すべて問題なければ、外部フラッシュからARMのフラッシュのメインプログラム領域にイメージを転送します。
保留中のアップグレード情報がEEPROMから消去され、ハードループが再起動を強制します。今回は、ブートローダーが通常の方法でメインアプリケーションを起動します。
更新フェーズが失敗するのを見たことはありませんが、展開前に新しいファームウェアリリースをテストすることは、この方法を使用することが重要です。新しいリリースがGSMネットワークに接続できず、将来のアップデートコマンドを受け入れることができない場合、オンサイトファームウェアアップデートが必要になります。
LinuxまたはRTOS、またはベアメタルを実行していますか?Debianを使用している場合は、現在のファイルシステムのスナップショットを取得し、「apt-get」を介してアップグレードを実行してから、機能したかどうかに応じて変更を保持またはロールバックします。