回答:
コードに必要なフラッシュメモリの2倍以上の量のチップを使用してください。これにより、何かがうまくいかない場合に備えて古いファームウェアを残したまま、このメモリに新しいファームウェアを取得できます。
新しいファームウェアのチェックサムを復号化して検証した後、ブートローダーはそれを最終的な場所にコピーし、古いファームウェアを置き換えます。この部分で何か問題が発生した場合、ハードリセット後、ブートローダーは新しいファームウェアが無効であることを確認し（もう一度チェックサムを実行して）、コピーを再試行します。
これは、私が知っている最も簡単で確実な方法です。また、ブートローダーにコードをほとんど必要とせず、メインプログラムとブートローダーの間で機能を複製する必要もありません（ブートローダーに通信ロジックは必要ありません）。
ブートローダーと数KBの追加フラッシュを使用します。
アップグレードは、UART、USB、I2C、または別のプロトコルを介していくつかの特別なコマンドを送信することにより、ブートローダーによって実行されます。メインコードのみが更新されます-ブートローダーコードは、外部プログラマー（PIC用のJTAG / PICkitなど）を介してのみ変更されません。
更新が失敗した場合（停電、誰かが電線をつまずいたなどの理由で）、ウィジェットは機能しませんが、ブートローダーはまだ存在するため、アップグレードを再試行できます。
フラグがどこかのバイトに設定されると、メインコードが完全に更新されていないため、メインコードが正しく実行されなくなります。
お使いのデバイスが比較的高価であり、コストに余裕がある場合（そして、お客様はアップグレードを気にする場合）、これを行うことができます...
（一般的に、この手法では外部ストレージまたはjtagの不正な使用が必要です。.）
システムを停止して再プログラムできる固定プログラムマイクロ（小さなPICなど）を用意します。
「アップグレードプロセッサ」ファームウェアを変更できないため、問題が発生することはありません。
1）ユーザーはデバイスをアップグレードできます
2）アップグレードが失敗した場合、いつでも再試行できます。レンガにできない
3）ターゲットデバイスがブートローダーをサポートしていない場合（ブートローダーを実行したいだけの場合）でも、目的のデバイスを実行させることができます。
FPGA、DSP、およびその他のオッドボールターゲットで機能します。
本当にすてきなユーザーインターフェイスを持つことができます（PICでさえWebサーバーを実行できます。...）
製品に、ある種の単純なシリアルインターフェイス（できればEIA232）があることを確認してください。DB-9用のスペースがなければ、非標準のコネクタでも構いません。たとえば、TxD、RxD、およびグランドに必要なのはTRSコネクタだけです。
初めてデバイスをプログラミングするときは、ブートローダーを含めます。新しい機能が必要な場合は、遅かれ早かれブートローダー自体をアップグレードする必要があるため、これは可能な限り単純でなければなりません。（おそらくアップグレードすることさえできません）
次に、TRSコネクタ。スイッチ付きのジャックを使用して、コネクタの存在を検出できるようにします。リセットをすぐに確認し、プラグが存在する場合はブートローダーを起動し、そうでない場合はアプリケーションを起動します。このように、ブートローダーとユーザーアプリケーションプログラムは十分に分離されたままです。（チェックは実際にはブートローダーの一部です。アプリケーションのバージョンに関係なく必要になります。そうしないとブートローダーに入ることができません！）
「アップグレード」にはどのような機器が利用できますか？PC、USBスティック、マイクロSDカード？
1つの方法は、アプリケーションを取り外し可能なアイテム（USBスティック、SDカードなど）に入れることです。チップは、アイテムからアプリケーションをロードします。アップグレード担当者は、単にアイテムを交換して再起動します。
私が知っているARMおよびCortexマイクロコントローラーチップ（NXP、Atmel）にはすべて、シリアルブートローダーが組み込まれているため、アップデーターがPCとシリアルケーブル（およびCOMポートインターフェイスを用意している場合）更新。