STM32 GDB / OpenOCDコマンドとフラッシュおよびRAMデバッグ用の初期化
Eclipse内でフラッシュとRAMのデバッグに使用する適切なGDB/OpenOCD初期化と実行コマンド（外部ツール）、およびフラッシュとRAMのmakeファイルに組み込む必要のある適切な変更または追加に関する支援を探しています。もちろんこれが重要な場合は、このmcu用にビルドします。
mcu：STM32F103VET6
Zylin Embedded CDT、Yagarto Tools and Bins、OpenOCD.4でEclipseHeliosを使用しており、Olimex ARM-USB-OCDJtagアダプターを使用しています。
すでにARM-USB-OCDを構成し、Eclipseの外部ツールとして追加しました。 OpenOCDを初期化するために、Eclipseで次のコマンドを使用しました。ボード設定ファイルはstm32mcuを参照します。
"openocd -f interface/olimex-arm-usb-ocd-h.cfg -f board /stm32f10x_128k_eval.cfg"
これをEclipse内で実行すると、すべてが機能しているように見えます（GDBインターフェイス、OpenOCDがmcuを検出するなど）。 OpenOCDにtelnetしてコマンドを実行することもできます。それで、私は次の部分で立ち往生しています。フラッシュとRAMのデバッグ、およびフラッシュの消去のための初期化とコマンド。
私はいくつかのチュートリアルを読み、ネットを調べましたが、このプロセッサに固有のものを見つけることができませんでした。私はこれに慣れていないので、例として同等の製品を認識していない可能性があります。
JimT
同じツールチェーンを使用して、STM32F107ボードをプログラムおよびデバッグしています。以下は、このツールチェーンの下でSTM32Fxxxチップをプログラムおよびデバッグするための私の観察結果です。
最初の出発点
したがって、この時点で、OpenOCDからARM-USB-OCDへの接続が機能しているので、すべての設定が完了しているはずです。現在、Eclipse/Zylin/Yagarto GDBの組み合わせを取得して、OpenOCD/Olimex接続を介してSTM32Fxxxと適切に通信できるようにする作業が行われています。覚えておくべきことの1つは、発行するすべてのOpenOCDコマンドが実行モードコマンドであることです。 OpenOCDサーバーを呼び出すための構成スクリプトとコマンドラインオプションは、構成モードコマンドです。 initコマンドを発行すると、サーバーは実行モードに入り、次に必要なコマンドのセットが開きます。あなたはおそらくどこかでそれをしましたが、私が次のようにOpenOCDサーバーを呼び出すとき、私は '-c "init"'オプションに取り組みます：
openocd -f /path to scripts/olimex-arm-usb-ocd-h.cfg -f /path to targets/stm32f107.cfg -c "init"
次に発行する次のコマンドは、EclipseDebug Configurationsダイアログによって実行されます。 Zylin Embedded debug（Native）セクションで、新しい構成を作成し、名前、プロジェクト（オプション）、およびプログラムするバイナリへの絶対パスを指定します。 [デバッガー]タブで、デバッガーを埋め込みGDBに設定し、Yagarto GDBバイナリパスをポイントしますしないでくださいGDBコマンドファイルを設定し、GDBコマンドをStandardに設定し、プロトコルをmi。
[コマンド]タブ-GDBをOpenOCDに接続します
したがって、次のタブはCommandsタブであり、そこに問題の核心があります。 2つのスペースInitializeとRunがあります。 GDBの呼び出しの前後に発生すると推測する以外は、違いが正確に何であるかはわかりません。いずれにせよ、コマンドの実行方法の違いに気づいていません。
しかしとにかく、ネットで見つけた例に従って、Initializeボックスに次のコマンドを入力しました。
set remote hardware-breakpoint limit 6
set remote hardware-watchoint-limit 4
target remote localhost:3333
monitor halt
monitor poll
最初の2行は、GDBにブレークポイントとウォッチポイントの数を示しています。 Open OCD Manual Section 20. GDBはその情報を照会できないと言っているので、私はそれを自分で言います。次の行は、ポート3333を介してローカルホストのリモートターゲットに接続するようにGDBに指示します。最後の行はmonitorコマンドで、GDBにコマンドを取得せずにターゲットに渡すように指示しますアクション自体。この場合、ターゲットはOpenOCDであり、コマンドhaltを与えています。その後、OpenOCDに非同期モードの操作に切り替えるように指示します。以下の操作には時間がかかるものがありますので、OpenOCDをブロックせずにすべての操作を待つと便利です。
補足＃1：GDBまたはOpenOCDの状態について疑問がある場合は、Eclipseデバッグコンソールを使用してコマンドをGDBまたはこのデバッグ構成を呼び出した後のOpenOCD（GDBモニターコマンドを介して）。
[コマンド]タブ-ユーザーフラッシュの設定
次に、Runコマンドセクションで指定するコマンドを示します。
monitor flash probe 0
monitor flash protect 0 0 127 off
monitor reset halt
monitor stm32x mass_erase 0
monitor flash write_image STM3210CTest/test_rom.elf
monitor flash protect 0 0 127 on
disconnect
target remote localhost:3333
monitor soft_reset_halt
次のセクションで説明します。
ユーザーフラッシュメモリへのアクセスの設定
まず、OpenOCDクエリを発行して、フラッシュモジュールを見つけ、適切なアドレスを報告できるかどうかを確認します。アドレス0x08000000でフラッシュが見つかったと応答した場合は、問題ありません。最後の0は、フラッシュバンク0に関する情報を取得することを指定します。
サイドノート＃2：STM32Fxxx部品固有のデータシートには、セクション4にメモリマップがあります。チップを操作するときに手元に置いておくと非常に便利です。また、すべてがメモリアドレスとしてアクセスされるため、少しプログラミングした後、手の甲のようなこのレイアウトを知ることができます。
したがって、フラッシュが適切に構成されていることを確認した後、コマンドを呼び出してフラッシュバンクへの書き込み保護をオフにします。 PM0075 フラッシュメモリのプログラミングについて知っておく必要のあるすべてのことを説明しています。このコマンドで知っておく必要があるのは、フラッシュバンク、開始セクター、終了セクター、および書き込み保護を有効にするか無効にするかです。フラッシュバンクは、OpenOCDに渡した構成ファイルで定義されており、前のコマンドで確認されています。フラッシュスペース全体の保護を無効にしたいので、セクター0〜127を指定します。PM0075は、フラッシュメモリが私の（およびあなたの）デバイス用に2KBページに編成される方法を参照するため、その番号を取得した方法を説明します。私のデバイスには256KBのフラッシュがあるので、128ページあります。デバイスには512KBのフラッシュがあるため、256ページになります。デバイスの書き込み保護が正しく無効になっていることを確認するには、OpenOCDコマンドを使用してアドレス0x40022020のFLASH_WRPRレジスタを確認します。
monitor mdw 0x40022020
結果として出力されるWordは0xffffffffになります。これは、すべてのページで書き込み保護が無効になっていることを意味します。 0x00000000は、すべてのページで書き込み保護が有効になっていることを意味します。
サイドノート＃3：メモリコマンドに関して、アドレス0x1ffff800で始まるブロックのオプションバイトをいじっていたので、チップを2回ブリックしました。 。初めてフラッシュに読み取り保護を設定しました（これを行うと何をしているのかわかりません）。2回目はハードウェアウォッチドッグを設定しました。これにより、ウォッチドッグが発光し続けたため、その後は何もできなくなりました。 OpenOCDメモリアクセスコマンドを使用して修正しました。物語の教訓は次のとおりです：大きな力には大きな責任が伴います...。 または別の見方は、私が自分の足を撃った場合でも、JTAGを介して問題を修正できるということです。
サイドノート＃4：保護されたフラッシュメモリに書き込もうとすると、FLASH_SR：WRPRTERRビットが設定されます。 OpenOCDは、よりユーザーフレンドリーなエラーメッセージを報告します。
フラッシュを消す
したがって、書き込み保護を無効にした後、プログラムするメモリを消去する必要があります。私はすべてを消去する一括消去を行います。セクターまたはアドレスで消去するオプションもあります（私は思います）。どちらの方法でも、書き込みを許可する前にハードウェアが最初に消去をチェックするため、プログラミングの前に最初に消去する必要があります。プログラミング中にFLASH_SR：PGERRビット（0x4002200c）が設定された場合は、そのメモリチャンクをまだ消去していないことがわかります。
補足＃5：フラッシュメモリのビットを消去することは、それを1に設定することを意味します。
バイナリのプログラミング
消去後の次の2行は、バイナリイメージをフラッシュに書き込み、書き込み保護を再度有効にします。 PM0075でカバーされていないということはこれ以上ありません。基本的に、flash write_imageを発行したときに発生するエラーは、フラッシュ保護が無効になっていないことに関連している可能性があります。おそらく[〜＃〜] not [〜＃〜]OpenOCDですが、興味がある場合は、デバッグ出力を有効にして、その動作に従うことができます。 。
GDBデバッグ
したがって、最後にプログラミング後、GDBをリモート接続から切断してからターゲットに再接続し、ソフトリセットを実行すると、GDBをデバッグする準備が整います。この最後の部分は、プログラミング後、GDBがリセット後にmain（）で適切に停止しない理由を理解しようとしていたときに、昨夜理解しました。それは雑草の中に入り込み、爆破し続けました。
私の現在の考えと、OpenOCDおよびGDBのマニュアルで読んだことから、リモート接続は、何よりもまず、GDBとすでに構成および実行されているターゲットとの間で使用されることを意図しているということです。実行する前にGDBを使用して構成しているので、プログラミング中にシンボルテーブルやその他の重要な情報が台無しになると思います。 OpenOCDのマニュアルによると、GDBが接続するとサーバーはメモリとシンボルを自動的に報告しますが、チップがプログラムされると、その情報はすべて無効になる可能性があります。切断と再接続GDBが適切にデバッグするために必要な情報を更新すると思います。そのため、別のデバッグ構成を作成することになりました。GDBを使用するたびにチップをプログラムする必要がないため、これはターゲットを接続してリセットするだけです。
ふぅ！完了！ちょっと長いですが、これは私が理解するのに3週間かかったので、それほど悪くはないと思います...
最後の補足：デバッグ中に、OpenOCDのデバッグ出力がOpenOCDが内部で何をしているかを理解するのに非常に貴重であることがわかりました。 STM32xチップをプログラムするには、フラッシュレジスタのロックを解除し、右ビットを反転する必要があり、一度に書き込むことができるのはハーフワードのみです。しばらくの間、OpenOCDがこれを適切に実行しているかどうかを疑問視していましたが、OpenOCDデバッグ出力を調べて、PM0075命令と比較した後、各操作を実行するための適切な手順に従っていることを確認できました。また、OpenOCDがすでに実行している手順を複製していることがわかったので、役に立たなかった指示を切り取ることができました。 ストーリーの教訓：デバッグ出力はあなたの友達です！
JLinkをSTM3240XXで動作させるのに苦労し、JLink GDBサーバーのドキュメントで、フラッシュをロードした後、「ターゲットリセット」を発行する必要があるというステートメントを見つけました。
「フラッシュでデバッグする場合、フラッシュのダウンロード後にターゲットをリセットすると、スタックポインタとPCが自動的に設定されます。ダウンロード後にリセットしない場合、スタックポインタとPCは、通常は.gdbinitファイルで正しく初期化する必要があります。」
Eclipseのデバッガーセットアップの[実行]ボックスに「ターゲットリセット」を追加すると、突然すべてが機能しました。 KinetisK60ではこの問題は発生しませんでした。
このドキュメントでは、リセットを発行したくない場合に、スタックポインタとPCを手動で直接設定する方法についても説明しています。問題を解決するのは切断/接続ではなく、リセットである可能性があります。
[コマンド]タブの最後の文の後に使用するもの-'実行'コマンドは次のとおりです。
symbol-file STM3210CTest/test_rom.elf
thbreak main
continue
thbreak main文は、gdbをmainで停止させるものです。