現在、RT1050で特定のFreeRTOSタスク内でブレークポイントを試みているのですが、ブレークポイントに達したときにデバッガーが自ら一時停止できず、手動でデバッガーを一時停止しようとすると「割り込み失敗」というダイアログが表示されます。
なので、私のアプリケーションは正常に起動します。プログラムを手動で一時停止すると、有効なデバッガーコンテキストが得られます。
これは私が介入したいタスクなので、メッセージキューの受信コールが戻った直後のswitch()文にブレークポイントを設定しています。また、そのすぐ下にNetIfInit()という方法内に2つ目のブレークポイントを設定しています。デバッガはその両方、あるいは少なくともどちらかに当てると思います。
また、メッセージキューへの送信を開始するブレークポイントをテスト関数内に設定しました。シリアルコンソールでキーを押すと、デバッガーがそのブレークポイントに到達して停止します。
次に、NetInit() 関数にステップインします。この関数は最終的に xQueueSend() を呼び出し、デバッガーはしばらくの待機の後、その関数にステップインします。次に、xQueueGenericSend() の本体を順に処理していき、この箇所に到達します。
846行目をステップオーバーしようとすると、デバッガーがしばらく停止した後、コンテキストを失います。履歴書の全て、すべてを一時停止、全て終了するボタンを失い、左側のスレッドリストも失っています。このセッションで使用できるボタンは、「一時停止」と「終了」のみです。一時停止をクリックすると、IDEは数秒間待機し、その後次のダイアログが表示されます。
これで終わりだ。デバッガーのゲームオーバーだ。一方、私のシリアルコンソールは、書きかけのUART出力で停止している。「やばい、スタックを全部使い果たしちゃった、ターゲットは死んだに違いない」と思うかもしれないが、そうではない。残っているボタンは赤い「終了（停止）」ボタンだけで、それをクリックするとデバッグセッションが終了し、実行が再開されます。タスクは正常に動作しています。
Initialize eth0.
#DA4 12.996 | eth: netif init
#DA4 12.999 | eth: NV MAC = 00-07-F0-00-56-03
#DA4 12.999 | eth: NV cfg: address = 192.168.1.180, netmask = 255.255.252.0, gateway = 192.168.1.1, static
#DA4 13.000 | eth: netif add: MAC 00-07-F0-00-56-03, PHY address 3
Returning to main menu.
#BB4 17.572 | No Handle Base Curr HiWByte State Name
#BB4 17.575 | 10 80010db8 19 19 824 Blocked Tmr Svc
#BB4 17.575 | 05 20206b68 12 12 1396 Suspended led_act
#BB4 17.576 | 04 20206500 12 12 1388 Blocked led_cpu
#BB4 17.576 | 08 2020ba18 8 8 7216 Blocked tcpip_thread
#BB4 17.576 | 07 20209868 7 7 6900 Blocked eth_mgr
#BB4 17.577 | 06 20207818 4 4 1912 Blocked gui
#BB4 17.577 | 01 20203538 3 3 2812 Suspended debug_mgr
#BB4 17.577 | 02 20204a68 2 2 4248 Running test
#BB4 17.577 | 03 20205e88 1 1 3948 Blocked backgrnd
#BB4 17.579 | 09 80010d40 0 0 748 Ready IDLEつまり、実行は設定したブレークポイントで実際に止まったようですが、デバッガが自ら故障しただけです。
なぜデバッガがこんなふうに狂ったのか、心当たりはありますか?
（追記：コンソール出力の添付ファイルを追加しました。もし役に立つようでしたら。）
デビッド・ロジャース
私も似たような状況で、デバッガがmain()で停止せず、その後は一時停止できず、「割り込み失敗」と表示されることがあります。ワークスペースディレクトリ「.mcuxpressoide_packages_support」を置き換えることで問題を解決しました。および「.metadata」私が持っていたバックアップを使って。
これらのディレクトリは別のコンピュータのインストールから入手できるかもしれません。
プロジェクトを再インポートするだけでも解決するかもしれません。
この問題が解決されたかどうかも知りたいです。私もまったく同じ問題を抱えています。MCUXpresso(v11.4)を使っているのですが、FreeRTOSアプリは何時間も問題なく動作します。手動でデバッガーを一時停止してコードをステップで進めることができます。しかし、私のプログラムは最終的にクラッシュし、デバッガ（Segger JLink経由）は「割り込み失敗」と報告するだけで、デバッグ機能がすべて失われてしまいます。
こんにちは、皆さん。
私たちも現在、同じ問題を抱えています。
問題のデバッグを行おうとしたのですが、ブレークポイントに到達した後、J-Linkデバッガーに「割り込みに失敗しました」と表示されます。
このスレッドはサポートシステムへのヒントで終わりますが、もう解決策はあるのでしょうか?
敬具
デビッド
こんにちは、エーリッヒさん。
えっ…まだチケット制なの？NXPは何年も前にフォーラムに行くように言ってそのサポートを閉ざしたと思っていました。(当時はあまり喜びませんでした。なぜなら、これはカスタマーサービスの削減、つまり「私たちに来るな、一般の方に助けを求めろ」と受け取ったからです。)しかし、NXPのエンジニアたちはフォーラムに積極的に参加しているようで、第三者からの意見は通常役に立つ。
サポートチケットをどこで送信できるか、簡単なリンクはありますか?もし今週中に割り切れるなら(笑)、少なくともEVKB上で正しく動作しつつ、ブレークポイントの失敗を示すバージョンを作れるか試してみます。ありがとう。
デビッド・R.
こんにちは、デイビッドさん。
通常のサポートチケットを使ってプロジェクトを提出することもできます。IDEエンジニアにとっては、EVK上で動作するハードウェアが手元にあるので、プロジェクトが小さいほど良いと思います。
ご協力いただきありがとうございます！
エーリッヒ
現在、他にも多くの案件を抱えていますが、数日中に追加情報をお伝えできるよう努めます。おっしゃる通り、私はフォーラムに自分のプロジェクトを投稿するつもりはありませんが、もしあなたやNXPのエンジニアに直接プロジェクトを送れる裏ルートがあれば、それで構いません。しかし、現在のプロジェクトの形態では、100％再現可能です。もし私のプロジェクトをプライベートで送ってもらえるなら、EVKB上で動作しつつも問題が残る修正版を作ってみます。
デビッド・R.
こんにちは、デイビッドさん。
私も時々同じ経験がありましたが、再現可能なケースはできなかったので、プロジェクトを共有することはできないと思います(そうでなければ、ぜひ共有してください)。
私が気づいたこと、あるいは考えていることは、SEGGER FreeRTOSの認識実装に問題がある可能性があるということです。大量のデータ読み取りが行われ、ビューの更新が頻繁に発生していることに気づきました。その件に関して、SEGGER社に問い合わせが保留されています。
確実に効果があったのは、デバッガでSEGGER FreeRTOS認識を無効にしたことです(ただし、これだとFreeRTOSアプリケーションのデバッグがユーザーフレンドリーで劣るのは認めます)。
もう一つやったことは、トラフィックを減らすために、できるだけ多くのビュー（特に分解ビュー）を閉じることでした。
理想的ではないことは承知していますし、もしIDEエンジニアリングチームのために他に何か教えていただけると助かります。
役立つかもしれないのはGDBトレースです。 EclipseのBoard Bring-Up Tips、GDBログとトレースを参照してください。MCUのエクリプス
お役に立てば幸いです。
エーリッヒ