STM32 USB大容量ストレージブートローダー

ソフトウェアは永久に追加できることが知られており、ボード上のあらゆる種類の欠陥は3番目のバージョンの修正によって完全に修正されます。 そして、ハードウェアに関して何もすることがなければ、ファームウェアを更新するために、スペースと時間の制限を回避する良い方法を思いつきました- ブートローダー 。



ブートローダーは便利で便利ですね。 また、ローダーが独自の実装である場合は、さらに便利で便利で柔軟性があり、安定していません 。 そしてもちろん、とてもクールです！



また、これは、使用しているコンピューター（この場合は、ARM Cortex-M3コアを備えたSTM32マイクロコントローラー）の機能をさらに深く掘り下げて調査する絶好の機会です。



実際、ブートローダーは一見すると思われるよりも簡単です。 証拠として、私たちは独自のUSB大容量ストレージブートローダーを組み立てます！







マイクロコントローラ（以下、MK） STM32F103RETで自家製のマザーボードを使用します。 不要な写真で出版物をいっぱいにしないために、この鉄片の切り捨て図を示します。







ブートローダーを作成するとき、私は次の原則に導かれました。

1. ブートローダーは非常に必要であり、TODOリストでそれを延期するのに十分です。座って実行する時間です。
2. ブートローダーには、ユーザーフレンドリーなプログラム読み込みインターフェイスが必要です。 ドライバー、サードパーティプログラム、アダプターボード、またはターゲットデバイスへのMGTFハーネスはありません。 自動検出されたUSBフラッシュドライブよりも簡単なものは何ですか？
3. ブートローダーモードで動作するには、マイクロコントローラーに最小限のハードウェア（実際には、USB、クォーツ、ボタンのみ）が必要です。
4. ブーツのサイズはポイントではありません。 もちろん重要ですが、数キロバイトに圧縮するという目標を追求しません。 良心の痛みなしに、USBスタックを上げ、ファイルシステムを操作し、 printf（）を行に貼り付けて、通常は何も拒否しません（hello、 Standard Peripheral Libraries ！）。

運転した

フラッシュについて少し

STM32フラッシュメモリを常に頻繁に使用するため、この事実に関連する重要な点をすぐに説明する価値があります。



使用済みのMKには512 Kバイトのフラッシュメモリが含まれています。 2048バイトのページに分割されます。









私たちにとって、これは、任意のアドレスにほんの数バイトを書き込むだけでは機能しないことを意味します。 FLASHに書き込む場合、必要なセルのみをゼロにすることができますが、単位の設定は消去操作を使用して実行され、その最小可能ボリュームは1ページです。 これを行うには、 FLASH_ARレジスタを使用します。このレジスタでは、必要なページ内の任意のアドレスを書き込むだけで十分であり、0xFFバイトで埋められます。 また、消去/書き込み操作の前に、フラッシュのロックを解除することを忘れないでください。



FLASHをいくつかの領域に仮想的に分割します。各領域にはそれぞれ固有の目的があります。

• BOOT_MEM-ブートローダーに割り当てられたメモリ領域。
• USER_MEM-ここにユーザーファームウェアを保存（およびここから実行）します。 明らかに、現在は200 Kバイトの制限があります。
• MSD_MEM-コンピューターとお気に入りのOSを使用してファームウェアをドロップできる大容量記憶ディスクがあります。
• OTHER_MEM-念のため、さらにスペースを空けましょう。

USER_MEMは、サイズがMSD_MEMと一致します。 これは論理的です、なぜなら 2つの正反対の場合は、 USER_MEMのメモリ不足または過剰を与えます。



そして今、すべては同じであり、マシン（およびプログラマーの利便性）のみです。

#define FLASH_PAGE_SIZE 2048 //2 Kbyte per page #define FLASH_START_ADDR 0x08000000 //Origin #define FLASH_MAX_SIZE 0x00080000 //Max FLASH size - 512 Kbyte #define FLASH_END_ADDR (FLASH_START_ADDR + FLASH_MAX_SIZE) //FLASH end address #define FLASH_BOOT_START_ADDR (FLASH_START_ADDR) //Bootloader start address #define FLASH_BOOT_SIZE 0x00010000 //64 Kbyte for bootloader #define FLASH_USER_START_ADDR (FLASH_BOOT_START_ADDR + FLASH_BOOT_SIZE) //User application start address #define FLASH_USER_SIZE 0x00032000 //200 Kbyte for user application #define FLASH_MSD_START_ADDR (FLASH_USER_START_ADDR + FLASH_USER_SIZE) //USB MSD start address #define FLASH_MSD_SIZE 0x00032000 //200 Kbyte for USB MASS Storage #define FLASH_OTHER_START_ADDR (FLASH_MSD_START_ADDR + FLASH_MSD_SIZE) //Other free memory start address #define FLASH_OTHER_SIZE (FLASH_END_ADDR - FLASH_OTHER_START_ADDR) //Free memory size
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メモリを領域に分割することに合意したら、今度はこれらすべてがどのように相互作用するかを理解する時が来ました。 ブロック線図を描きましょう：









このアルゴリズムによると、ブートローダーには、互いに独立して動作する2つのメインモードがありますが、共通のリソース（ MSD_MEMメモリの一部）があります。 ただし、その使用はさまざまな時点で発生するため、ブートローダーの安定性にプラスの影響を与え、プログラミングおよびデバッグプロセスを簡素化します。

1. 最初のモードは、外部ドライブとして利用可能なMSD_MEM領域でユーザーソフトウェアを受信および保存する役割を果たします。
   
   
   
   
2. 2番目のモードでは、 MSD_MEMで「APP.BIN」という名前のファイルが存在するかどうかをチェックし、その整合性、信頼性をチェックします。また、空またはファームウェア「APP.BIN」がより新しい場合はUSER_MEMに移動します。

各モードをさらに詳しく検討します。

USB大容量デバイス

対応する開始条件が満たされた場合、 メイン（）を入力した直後に開始します-ボタンがクランプされます。 私のボードでは、これはオン/オフスイッチの上部のスライダーです（ちなみに、MK BOOT0およびBOOT1（PB2）の脚に巻き付けられています。これにより、必要に応じてハードウェアUARTローダーMKを使用できます）。





大容量記憶モードでの作業は、STMicroelectronics（ STM32_USB-FS-Device_Lib_V4.0.0 ）の例から取られており、Webサイトからダウンロードできます。 そこでは、USB MSDモードでSDIOを介して接続されたマイクロコントローラーとメモリカードを使用することがどのように必要であるか（またはその逆、必要ではない-STからのライブラリーに対する態度が常に前向きではない）を示しています。 この例では、64バイトのパケット長を持つ2つのバルクイン/アウトエンドポイントと、SCSIが機能するために必要な一連のコマンドを実装しています。 ここからSDカードまたはNANDメモリ（mass_mal.c / .h）に関連付けられた関数を破棄し、内部フラッシュに置き換えます：









接続がすべて正しく行われると、コンピューターは製品をUSB大容量記憶装置として識別し、フォーマットするように提案します。 ごみはMSD_MEM領域にあります。 この動作モードでは、MKはホストとFLASHメモリの間の単なる仲介者であり、オペレーティングシステムがドライブ上にどのデータとどのアドレスを置くかを独自に決定することに注意してください。



ディスクをフォーマットし、それがMSD_MEM領域にどのように影響するかを確認します。







ボリュームは同じで、Windowsセクターのサイズは正しいと判断され、ゼロセクターは起動可能で、メモリ内の場所は計画に対応しています。 ファイルは書き込まれ、読み取られ、停電後も消えません-200 Kバイトのフルフラッシュドライブ！

ブートローダー

ファームウェアの更新が不要な場合に開始します。 つまり、デバイスの通常の動作です。 その中で、ユーザーソフトウェアを正常に起動するために必要ないくつかの基本的なアクションを実行する必要があります。 基本-必要に応じて、暗号化、整合性チェック、デバッグメッセージの出力など、あらゆる種類の機能を使用してブートローダーの作業を補完できるため



Windowsを使用してUSBドライブ上のファイルシステムを既に作成し、必要なソフトウェアをダウンロードしたとします。 これで、MKの目でメディアの内容を見ることができればうれしいです。つまり、 FatFS （マイクロコントローラ上の小さな組み込みシステム用に設計されたシンプルなFATファイルシステムモジュール）のComrade ChaNにアクセスします。 ダウンロードしてプロジェクトにドロップし、ディスクから必要なデータを読み取る機能を処方します。





disk_write（）は不要です。マウントされたファイルシステムは読み取り専用であるため、スタブのままです。 これは、 ffconf.h構成ファイルで設定することもでき、不要な機能や未使用の機能をすべて無効にします。



その後、すべてが多かれ少なかれ明らかです：ファイルシステムをマウントし、ファームウェアファイルを開き、読み始めます。 最初は、ファームウェアのメインストレージの場所がMSD_MEMになるように実装されており、マイクロコントローラーはオンになるたびにフラッシュメモリを上書きします。 ファームウェアの不在およびwhile（TRUE）に関するデバッグメッセージはありません。 ファームウェアがあります-USER_MEMにスローします 。 ただし、このようなソリューションの明らかなマイナス点は、フラッシュメモリの消去/書き込みリソースに制限があり、製品を徐々に意識的に殺すのは愚かであることです。



したがって、 「APP.BIN」とUSER_MEMを、バイトごとに愚かに比較してください。 おそらく、2つの配列のハッシュ和を比較することは、よりエレガントなソリューションのように見えますが、確かに最速ではありません。 main（）をもう一度見てみましょう：





比較中にサイクルの最後に到達しなかった場合、ファームウェアは異なり、 CopyAppToUserMemory（）を使用してUSER_MEMを更新します。 それでは、 PeriphDeInit（）を呼び出してからGoToUserApp（）を呼び出して、ブートローダーのトレースを破棄するとよいでしょう。 しかし、これは少し後ですが、今のところ-コピープロセス：





512バイトのブロックでコピーします。 512-バッファサイズがこの値よりも大きいと、 f_read（）が刈ることができる場所を見たからです。 私はこの点をチェックしました-すべてがより大きなバッファーで私のために働いた。 しかし、念のため、彼は512を残しました-どうしてですか？ RAMを節約し、速度に影響を与えません。さらに、1回だけ実行されます。デバイスの電源を入れた瞬間に、ファームウェアを更新するときだけです。



まず、フラッシュメモリ内のファイルの場所を消去します。 消去された領域のサイズは、 「APP.BIN」が完全に占有するメモリ内のページ数+もう1つ（満杯ではない）に等しくなります。 また、事実上、「body」と「tail」でファームウェアファイルを破りました。ここで、「body」はファイルの最大可能部分であり、512バイトの整数ブロックと「tail」-その他すべてです。



すべてのバイナリファームウェアファイルは4バイトの倍数であるようです。 私はこれを確実に（そしてまだ）確信していなかったので、念のため-ファームウェアがsizeof（u32）の倍数でない場合-0xFFバイトで補完します。 繰り返しますが、これは実行する必要はないようですが、複数のsizeof（u32）バイナリに対して操作は無害であるため、そのままにします。

こんにちは、User Application！

もうすぐ。 PeriphDeInit（）関数で使用されるすべての周辺機器の初期化を解除します（ほとんど何もありません-モードボタンのGPIO、および必要に応じてデバッグメッセージを出力するUART、割り込みは使用されません）。



ブートローダーの最終的なライフステージは、カスタムファームウェアの実行の開始です。





わずか5行ですが、どれくらい続いていますか！



ARM Cortex M3カーネルでは、例外が発生すると、対応するハンドラーが呼び出されます。 例外ハンドラの開始アドレスを決定するために、ベクターテーブルメカニズムが使用されます。 ベクタテーブルは、システムメモリ内のデータワードの配列で、それぞれが1種類の例外の開始アドレスです。 テーブルは移動可能であり、SCB（システムコントロールブロック）の特別なVTORレジスターによって移動が制御されます（マニュアルでは涼しく聞こえますが、壊れました： ベクターテーブルは再配置可能で、再配置はNVICの再配置レジスターによって制御されます）。 RESET後、このレジスタの値は0です。つまり、ベクターテーブルは0x0にあります（スタートアップファイルのSTM32F103の場合、既に0x08000000に移動しています）。 そして、これは私たちにとって非常に重要です、そこにある順序は次のとおりです。

• 0x04の値は、 リセット例外の後に取得するプログラム内の場所です。
• 0x00の値は、ユーザーアプリケーションの初期メインスタックポインター値です。

これらすべてを合わせて、機能へのポインタを使用した魔法を追加すると、アリスはウサギの後にジャンプします。



次に、それがまったく機能するかどうかを確認しましょう。 main（）のサイクルといくつかの割り込み（SysTickとTIM4）を使用して、LEDを点滅させる簡単なプログラムを作成してみましょう。





ところで、プロジェクト内のいくつかの問題を修正することを忘れてはなりません。

1. SystemInit（）から、何らかの値（ // SCB-> VTOR = FLASH_BASE ）でベクターテーブルを移動する操作を削除します。 ブートローダーはユーザープログラムに移動する前に自分で移動します！
   
   
   
   
2. リンカースクリプトで、プログラムの開始をアドレス0x08000000から開始アドレスUSER_MEM （ FLASH（rx）：ORIGIN = 0x08010000、LENGTH = 200K ）に変更します。

そして、このコードが実行されます（LEDが点滅するのを誰もが見ないかもしれません...）：







ブートローダーを介したMKでのこのファームウェアのブートログは次のとおりです。





まとめると。 ブートローダーが判明しました！ そしてそれも機能します。 UARTでデバッグメッセージを出力すると、-25608バイトなしで31684バイトのフラッシュメモリを占有します。 大容量ストレージディスクに必要なメモリ量も考慮すると、それほど多くはありません。 ソースと作業ドラフト（Atollic TrueSTUDIO）は、 Bitbucketで表示できます。



ご清聴ありがとうございました！