ブートローダーは、プログラムするマイクロコントローラーで実行されるプログラムです。何らかの通信手段を介して外部から新しいプログラム情報を受信し、その情報をプロセッサのプログラムメモリに書き込みます。
これは、プログラムをマイクロコントローラーに取り込む通常の方法とは対照的です。マイクロコントローラーは、その目的のためにマイクロに組み込まれた特別なハードウェアを介しています。PICでは、これはSPIのようなインターフェイスです。私の記憶が正しければ、AVRはJtagを使用するか、少なくとも一部は使用します。いずれにせよ、これには情報をプログラムメモリに書き込むためにプログラミングピンを少しずつ動かす外部ハードウェアが必要です。プログラムメモリの内容を記述するHEXファイルは汎用コンピューターで作成されるため、このハードウェアは一方のコンピューターに接続し、他方のマイクロの特別なプログラミングピンに接続します。私の会社では、特にPICプログラマーを副業として作っているので、PICでのこのプロセスにはかなり精通しています。
特殊なハードウェアを介した外部プログラミングの重要なポイントは、プログラムメモリの既存のコンテンツに関係なく機能することです。マイクロコントローラーは、プログラムメモリが消去された状態または未知の状態で開始されるため、最初のプログラムをマイクロに取り込む唯一の手段は外部プログラミングです。
製品にロードするプログラムについて確信があり、ボリュームが十分に大きい場合は、メーカーまたはディストリビューターのプログラムチップを入手できます。チップは他のチップと同様にボードにはんだ付けされ、ユニットは準備完了です。これは、たとえばおもちゃのようなものに適しています。ファームウェアが完成したら、ほぼ完成し、大量に生産されます。
ボリュームが小さい場合、またはさらに重要なことは、進行中のファームウェア開発とバグ修正を期待している場合、事前にプログラムされたチップを購入したくないということです。この場合、ブランクチップがボードにマウントされ、製造プロセスの一部としてファームウェアをチップにロードする必要があります。その場合、ハードウェアプログラミングラインを何らかの方法で利用可能にする必要があります。これは、明示的なコネクタを介して行うことも、実稼働テストフィクスチャを作成する場合はpogoピンパッドを介して行うこともできます。多くの場合、そのような製品はテストする必要があり、とにかくキャリブレーションする必要があるため、通常、プログラムをプロセッサに書き込むための追加コストは最小限です。小型のプロセッサを使用する場合、特別な生産テストファームウェアが最初にプロセッサにロードされることがあります。これは、ユニットのテストとキャリブレーションを容易にするために使用され、次に、ハードウェアが正常であることがわかった後、実際のファームウェアがロードされます。この場合、プログラミングプロセスが機能するのに十分なプログラミングラインへのアクセスを許可するだけでなく、回路に過度の不便を与えないために、いくつかの回路設計上の考慮事項があります。詳細については、インサーキットプログラミングの説明。
これまでのところ、ブートローダーは必要ありません。ただし、フィールドアップグレードが可能な比較的複雑なファームウェアを備えた製品、またはエンドカスタマーがアップグレードできる製品を検討してください。エンドカスタマーがプログラマガジェットを持っていると期待したり、たとえそれを提供したとしても適切に使用する方法を知ったりすることはできません。実際、私の顧客の一人がこれをしています。特別なフィールドカスタマイズオプションを購入すると、私のプログラマーが製品を入手できます。
ただし、ほとんどの場合、顧客にPCでプログラムを実行し、ファームウェアを魔法のように更新してもらいたいだけです。これは、特に製品にUSB、RS-232、イーサネットなどのPCと簡単に接続できる通信ポートが既にある場合、特にブートローダーが入ります。顧客は、すでにマイクロにあるブートローダーと通信するPCプログラムを実行します。これにより、新しいバイナリがブートローダーに送信され、プログラムメモリーに書き込まれた後、新しいコードが実行されます。
単純に聞こえますが、少なくともこのプロセスを堅牢にしたい場合はそうではありません。通信エラーが発生し、ブートローダーに到着するまでに新しいファームウェアが破損した場合はどうなりますか？起動プロセス中に電源が切断された場合はどうなりますか？ブートローダーにバグがあり、それ自体にがらくたがある場合はどうなりますか？
単純なシナリオでは、ブートローダーは常にリセットから実行されます。ホストとの通信を試みます。ホストが応答すると、ブートローダーに新しいものがないことを通知するか、新しいコードを送信します。新しいコードが到着すると、古いコードは上書きされます。アップロードされたコードには常にチェックサムが含まれているため、ブートローダーは新しいアプリに問題がないかどうかを確認できます。そうでない場合、有効なチェックサムを持つものがメモリにロードされるまで、ブートローダーに常にアップロードを要求し続けます。これは、常に接続されているデバイス、および場合によってはブートローダー要求に応答するホストでバックグラウンドタスクが実行されるデバイスで許容される場合があります。このスキームは、主に自律的であり、ホストコンピューターに接続するのはたまにしか行わないユニットには適していません。
通常、上記の単純なブートローダーは、フェイルセーフがないため受け入れられません。新しいアプリのイメージがそのまま受信されない場合、デバイスが古いイメージの実行を続け、アップロードが正常に実行されるまで停止しないようにします。このため、通常、ファームウェアには実際には2つの特別なモジュール、アップローダーとブートローダーがあります。アップローダーはメインアプリの一部です。ホストとの定期的な通信の一環として、新しいアプリの画像をアップロードできます。これには、外部EEPROMなどのメインアプリイメージとは別のメモリが必要か、より大きなプロセッサを使用するため、プログラムメモリ領域の半分を新しいアプリイメージの保存に割り当てることができます。アップローダーは受信した新しいアプリの画像をどこかに書き込むだけですが、実行はしません。アップロード後にホストからのコマンドで発生する可能性のあるプロセッサがリセットされると、ブートローダーが実行されます。これは現在、外部通信機能を必要としない完全に自己完結型のプログラムです。現在のバージョンとアップロードされたアプリのバージョンを比較し、それらのチェックサムをチェックし、バージョンが異なり、新しいイメージのチェックサムがチェックされる場合、新しいイメージをアプリ領域にコピーします。新しいイメージが破損している場合、以前のように古いアプリを実行するだけです。
多くのブートローダーを作成しましたが、同じものはありません。一部のマイクロコントローラ企業があなたに信じてほしいと思っているにもかかわらず、汎用のブートローダーはありません。すべてのデバイスには、ホストに対処するための独自の要件と特別な状況があります。以下は、私が使用したブートローダーの構成とアップローダーの構成の一部です。
- 基本的なブートローダー。このデバイスにはシリアル回線があり、ホストに接続され、必要に応じてオンになります。ブートローダーはリセットから実行され、いくつかのアップロード要求応答をホストに送信しました。アップロードプログラムが実行されている場合、応答して新しいアプリイメージを送信します。500ミリ秒以内に応答しなかった場合、ブートローダーはあきらめて既存のアプリを実行します。そのため、ファームウェアを更新するには、まずホストでアップデーターアプリを実行し、次にデバイスを接続して電源を入れる必要がありました。
- プログラムメモリアップローダー。ここでは、プログラムメモリが2倍になる次のサイズのPICを使用しました。プログラムメモリは、主に49％のメインアプリ、49％の新しいアプリイメージ、2％のブートローダーに分けられました。ブートローダーはリセットから実行され、適切な条件下で新しいアプリのイメージを現在のアプリのイメージにコピーします。
- 外部EEPROMイメージ。外部のEEPROMを使用して新しいアプリのイメージを保存したことを除いて、＃2と同様です。この場合、より多くのメモリを搭載したプロセッサも物理的に大きくなり、必要な周辺機器が混在していない別のサブファミリになります。
- TCPブートローダー。これはそれらの中で最も複雑なものでした。大きなPIC 18Fが使用されました。メモリの最後の1/4にブートローダーがあり、ブートローダーにはTCPネットワークスタックの完全なコピーがありました。ブートローダーはリセットから実行され、以前に構成されたIPアドレスの既知のポートで特別なアップロードサーバーに接続しようとしました。これは、システム全体に専用のサーバーマシンが常に存在する大規模なインストール用です。各小さなデバイスは、リセット後にアップロードサーバーにチェックインし、必要に応じて新しいアプリのコピーを提供します。ブートローダーは、既存のアプリを新しいコピーで上書きしますが、チェックサムがチェックされている場合にのみ実行します。そうでない場合は、アップロードサーバーに戻り、再試行します。
ブートローダー自体は完全なTCPネットワークスタックを含む複雑なコードであったため、フィールドアップグレードも可能でなければなりませんでした。彼らが行った方法は、アップロードサーバーに特別なアプリを提供し、実行されたブートローダーを上書きし、新しいブートローダーが実行されるようにマシンをリセットして、アップロードサーバーが最新のメインアプリの画像。技術的には、特別なアプリがブートローダーを介して新しいイメージをコピーするのにかかった数ミリ秒の間の電源障害は、回復不能な障害になります。実際には、これは決して起こりませんでした。これらのデバイスは大規模なインストールの一部であり、システムのメンテナンスを行う人々がすでにいたため、場合によっては他の理由で組み込みデバイスを交換することを意味するため、その可能性はほとんどありませんでした。
他の多くの可能性があり、それぞれがリスク、速度、コスト、使いやすさ、ダウンタイムなどのトレードオフを持っていることを願っています。