問題タブ [jtag]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c - K64F をフラッシュしようとしましたが、CPU を停止できませんでした
カスタム ボードに配置された Cortex M4 をプログラムしようとしています。プロセッサは MK64FN1M0VLL12 です。OpenSDA を使用して USB 経由でビンをロードする FRDM-K64F 開発ボードを使用してコードを作成しました。コードは mbed で書かれていますが、私の知る限り、プログラムをプロセッサにロードするためのサポートはありません。製品版のボードでは、OpenSDA インターフェースが含まれていなかったので、J-Link プログラマー経由でプログラムをロードすることを計画していました。
J-Link コマンダー ツールを使用して、何らかの応答を得るには、ボードのリセット ボタンを押し続ける必要があることがわかりました。リセットを押さないと、次のようになります。
ビンをロードしようとすると、CPU が停止していないというメッセージが表示されます。まだリセットを押しているかどうかに関係なく、これを取得します。
OK メッセージは少し誤解を招きます。LEDが点滅するだけのプログラムをアップロードしようとしたのですが、LEDが点滅しません。
ここからどこへ行けばいいのかわからない。グーグルの数日間は、私を実りある場所に導きませんでした。
gdb - マイクロコントローラのデバッグに GDB (Gnu Debugger) と OpenOCD を使用する方法 - ターミナルから?
ARM マイクロコントローラをプログラムする標準的な (低コストの) 方法は、複雑なツールチェーンがプラグインされた Eclipse を使用することです。Eclipse には確かにメリットがありますが、私はこの IDE から独立したいと考えています。ソフトウェアをビルド (コンパイル - リンク - フラッシュ) するとき、およびデバッグ セッションを実行するときに、舞台裏で何が起こるかを知りたいです。このように深く理解するには、コマンド ラインからすべての手順を実行するとよいでしょう。
注: 私は 64 ビットの Windows 10 を使用しています。ただし、ここで説明するほとんどの内容は、Linux システムにも適用されます。すべてのコマンド ターミナルを管理者権限で開いてください。これにより、多くの問題を回避できます。
1. ソフトウェアの構築
最初の「使命」は達成されます。コマンド ラインを使用して、ソフトウェアをコンパイルし、バイナリ.bin
とイメージにリンクできるようになりました。.elf
成功への鍵は、Eclipse が特定のプロジェクトのメイク ファイルを配置する場所を見つけることでした。それらがどこにあるかがわかったら、あとはコマンド ターミナルを開いてコマンドを入力するだけGNU make
です。
そのためにEclipseはもう必要ありません!特に、makefile を読んで (そして理解して)、プロジェクトが進んだときにニーズに合わせて微調整できる場合はなおさらです。
SW4STM32 (System Workbench for STM32) をインストールした後、GNU ツール (コンパイラ、リンカー、make ユーティリティ、GDB など) が次のフォルダーにあることに注意してください。
次に、ハードドライブに新しいフォルダーを作成し、これらすべての GNU ツールをそこにコピーしました。
そして、これらのエントリを「環境パス変数」に追加します。
Huray、これですべての GNU ツールをシステム上で稼働させることができました! build.bat
と同じフォルダに次のファイルを置きますmakefile
。
このバットファイルを実行すると、うまくいくはずです! すべてがうまくいけば、コンパイルの結果として.bin
1 つのバイナリ ファイルが得られます。.elf
2.ファームウェアのフラッシュとデバッグ
次の自然な手順は、ファームウェアをチップにフラッシュし、デバッグ セッションを開始することです。Eclipse では、「ボタンを 1 回クリックする」だけです。少なくとも、Eclipse がマイクロコントローラー用に正しく構成されていれば。しかし、舞台裏で何が起こっているのでしょうか? OpenOCD の開発者である Dominic Rath の修士論文 (の一部) を読みました。ここで見つけることができます: http://openocd.net/。これは私が学んだことです:
「デバッグ」アイコンをクリックすると、Eclipse は OpenOCD ソフトウェアを開始します。Eclipse は、OpenOCD にいくつかの構成ファイルも提供します。これにより、OpenOCD はマイクロコントローラーへの接続方法を認識します。「どのように接続するか」は簡単なことではありません。OpenOCD は、JTAG アダプター (STLink など) に接続するための適切な USB ドライバーを見つける必要があります。JTAG アダプターとその USB ドライバーは、通常、チップの製造元 (STMicroelectronics など) から提供されます。また、Eclipse は、マイクロコントローラーの仕様を記述した構成ファイルを OpenOCD に渡します。OpenOCD がこれらすべてを認識すると、ターゲット デバイスへの信頼性の高い JTAG 接続を確立できます。
OpenOCD は 2 つのサーバーを起動します。1 つ目は、TCP ポート 4444 の Telnet サーバーです。これにより、OpenOCD CLI (コマンド ライン インターフェイス) にアクセスできます。Telnet クライアントは、OpenOCD に接続してコマンドを送信できます。これらのコマンドは、単純な「停止」、「実行」、「ブレークポイントの設定」などです。
マイクロコントローラーのデバッグにはこのようなコマンドで十分かもしれませんが、多くの人はすでに Gnu Debugger (GDB) に慣れています。これが、OpenOCD が TCP ポート 3333 で GDB サーバーも起動する理由です。GDB クライアントはそのポートに接続して、マイクロコントローラーのデバッグを開始できます。
Gnu Debugger はコマンド ライン ソフトウェアです。多くの人が視覚的なインターフェースを好みます。それはまさにEclipseが行うことです。Eclipse は OpenOCD に接続する GDB クライアントを開始しますが、それはすべてユーザーには隠されています。Eclipse は、舞台裏で GDB クライアントと対話するグラフィカル インターフェイスを提供します。
これらすべてを説明する図を作成しました。
>> OpenOCDの起動
コマンドラインからOpenOCDを起動することができました。方法を説明します。
- まず、STLink-V2 JTAG プログラマが正しくインストールされていることを確認してください。STMicroelectronics の「STLink Utility ツール」を使用してインストールをテストできます。素敵な GUI を備えており、接続ボタンをクリックするだけです。
- 次に、Web サイトhttp://gnutoolchains.com/arm-eabi/openocd/から OpenOCD ソフトウェア実行可能ファイルをダウンロードします。それをインストールし、「C:\Apps\」のようなハード ドライブのフォルダーに配置します。
コマンド ターミナルを開き、OpenOCD を起動します。マイクロコントローラを探す場所を OpenOCD が認識できるように、いくつかの構成ファイルを OpenOCD に与える必要があります。通常、JTAG プログラマーを記述する構成ファイルと、マイクロコントローラーを定義する構成ファイルを提供する必要があります。
/li>-f
コマンドラインで引数を使用して、これらのファイルを OpenOCD に渡します。また、OpenOCD にフォルダーへのアクセス権を与える必要があります。これには、引数scripts
を渡します。-s
これは、コマンドラインを使用してコンピューターで OpenOCD を開始する方法です。OpenOCD を適切に (正しい引数で) 起動すると、次のメッセージが表示されて起動します。
/li>ターミナル ウィンドウがブロックされていることに注意してください。コマンドを入力することはできなくなります。しかし、それは正常です。OpenOCD はバックグラウンドで実行されており、ターミナルをブロックします。OpenOCD とやり取りするには 2 つのオプションがあります。別の端末で Telnet セッションを開始し、TCP ポート
localhost:4444
にログオンして、OpenOCD にコマンドを送信し、フィードバックを受け取ることができます。または、GDB クライアント セッションを開始し、TCP ポートに接続しますlocalhost:3333
。
>> OpenOCD と対話するための Telnet セッションの開始
これは、Telnet セッションを開始して、実行中の OpenOCD プログラムと対話する方法です。
正常に動作すると、端末に次のメッセージが表示されます。
これで、コマンドを OpenOCD に送信する準備が整いました! しかし、ここで GDB セッションに切り替えます。それが OpenOCD と対話する最も便利な方法だからです。
>> OpenOCD とやり取りするための GDB クライアント セッションの開始
さらに別のターミナル ウィンドウを開き、次のコマンドを入力します。
このコマンドは、arm-none-eabi-gdb.exe
GDB クライアントを起動するだけです。すべてがうまくいけば、GDB は次のメッセージで起動します。
次に、この GDB クライアントを OpenOCD 内の GDB サーバーに接続します。
これで、OpenOCD に接続されました。知っておくと便利: ネイティブの OpenOCD コマンドを使用する場合 (Telnet セッションで行う場合と同様)、コマンドの前にキーワードmonitor
. このようにして、OpenOCD 内の GDB サーバーはコマンド自体を処理せず、ネイティブの OpenOCD デーモンに渡します。
それでは、チップをリセットし、消去して停止します。
これで、チップは私たちからの指示を受け取る準備が整いました。最初に、フラッシュ セクション 0 から 7 (私の 1Mb チップのすべてのフラッシュ セクション) を保護しないようにチップに指示します。
次に、チップを再び停止します。念のために..
.elf
最後に、バイナリファイルを GDBに渡します。
今が真実の瞬間です。このバイナリをチップにロードするように GDB に依頼します。成功を祈っている:
残念ながら、それは成功しませんでした。OpenOCD で次のメッセージが表示されます。
編集: ハードウェアの問題が修正されました。
どうやらハードウェアの問題だったようです。STLink Utility ツールを使用してバイナリをチップにロードすると問題なく動作したので、自分のチップに欠陥があるとは思っていませんでした。OpenOCD だけが不平を言ってエラーを出していました。当然、私は OpenOCD を非難しました - チップ自体ではありません。詳細については、以下の私の回答を参照してください。
編集: チップをフラッシュする別のエレガントな方法 - makefile を使用!
問題が修正されたので、フラッシュを実行してチップをデバッグする別の方法に焦点を当てます。これはコミュニティにとって本当に興味深いことだと思います。
お気づきかもしれませんが、必要なすべての手順を実行するために Windows cmd コマンドを使用しました。これは、バッチ ファイルで自動化できます。しかし、もっと洗練された方法があります: makefile のすべてを自動化することです! さん/さん Othane は、彼/彼女の Cortex-M 用に次のメイクファイルを提案しましたか? チップ。Cortex-M7 チップの手順は非常に似ていると思います。
親愛なる Mr./Mss. Othane さん、次の手順でこの makefile を使用する方法を説明していただけますか。
- ソースコードからバイナリをビルドする
- チップをフラッシュする
私はメイクファイルの基本をいくつか知っていますが、あなたのメイクファイルは本当に奥が深いです。GNU make ユーティリティのかなりの機能を使用しているようです。もう少し説明をお願いします。ボーナスを差し上げます ;-)
------------------------------
arm - Cortex-M3 のデバイス固有の JTAG 命令はどこにありますか?
JTAG を介して Cortex-M3 ベースのマイクロコントローラー (LPC1769) と通信しようとしています。必要なハードウェアは既に用意されており、サンプル プログラムを動作させることができましたが、さらに先に進むには、この場合に使用できるデバイス固有の JTAG 命令を知る必要があります。Cortex-M3 テクニカル リファレンス マニュアル (リンク)の対応するセクションを読んだところ、デバイスが標準の CoreSight デバッグ ポートを使用していることがわかりました。特に、IDCODE命令でデバイスIDを読みたいです。一部のサイトでは、このデバイスの IDCODE は b0001 または b1110 であると示唆されていますが、どちらも機能していないようです。b0001 は、TAP がリセットされた後に IR から読み取った値であるため、私には可能性が高いようです。
また、使用している命令が正しく、デバイス ID レジスタを正しく読み取っていない可能性も考えました。FT232H チップを搭載した FTDI ケーブルを使用しています。使用しているアプリケーションは、MPSSE コマンドを使用した FTDI の AN129 サンプル コード (リンク) に基づいています。0x2A コマンドを使用して TAP からデータをクロック入力し、0x1B コマンドを使用してデータを TAP にクロック出力し、0x3B コマンドを使用して両方を同時に実行します。私が間違っていること(または正しいIDCODE命令を使用しているかどうか)について、誰かが洞察を提供できれば、それは大歓迎です。
*編集: ある程度の進歩はありましたが、IDCODE 命令はまだわかりません。TAP コントローラーを Test-Logic-Reset 状態 (IR に IDCODE 命令をロード) に設定した後、デバイス ID を読み取ることができました。ただし、考えられるすべての (16) 命令を試しましたが、DR からの読み取りが異なるものもありましたが、デバイス ID レジスタをロードしたものはありませんでした。
これは、TAP コントローラーが Shift-IR 状態になったら、命令を挿入するために使用する関数です。
length パラメーターは 4 に設定され、data パラメーターは 0x0X に設定されています (X のすべての可能な値を試しましたが、どちらも成功しませんでした)。