Stlink: st-utilはLIBUSB_ERROR_NO_DEVICEで終了する必要があります

stlinkはこの時点で終了する必要があると思います： https ：

stlinkはこの時点で終了する必要があると思います。

https://github.com/texane/stlink/blob/df3c2b02867db03fb82f6faaad71300398965e85/src/usb.c#L54

ええ、あなたは正しいと思います。libusbへの呼び出しは適切にチェックする必要があります。 必要に応じて、パッチを適用してPRを送信できます。 これは、usb.cファイル内のlibusbへの他の呼び出しに対しても実行する必要があります。 報告してくれてありがとう！

必要に応じて、パッチを適用してPRを送信できます。

私はしたいです。 ただし、プロジェクトの構造を理解しているかどうかはわかりません。そのため、ここでは単純なexit(1)十分かどうかはわかりません。

これは、usb.cファイル内のlibusbへの他の呼び出しに対しても実行する必要があります。

私はこれをよく理解していないかもしれません。 「 send_recvは-1返すところならどこでもアプリケーションを終了させる」という意味ですか？

PRにコメントを入れましたが、libusbを呼び出すとうまくいかない場所がたくさんあります。

プロジェクトは次のように構成されています。

• libstlink（usb.cはその一部であり、ライブラリでexitを使用しないでください）ライブラリのファイルはsrcフォルダーにあり、最も重要なのはusb.cとcommon.c（そしてもちろんflash_loader.c）です。
• st-utilはsrc / gdbserverにあります
• st-infoはsrc / tools /info.cにあります
• st-flashはsrc / tools /flash.cにあります

これは＃888と＃445に関連していると思います。
@ceremcemと@rewolff ：これについて一緒に議論するというアイデアはどうですか？

@chenguokai ：ここでどのように進めるかについてのアイデアはありますか？

この場合は再現できません。
macOSマシンで手順に従いました。 エラーメッセージが表示されますが、デッドループに入る兆候はありません。

編集： main関数にブレークポイントを設定し、st-linkを抜いた後、コマンドnを発行しました

パケットの送受信を無制限に再試行するのではなく、プログラムを終了する必要があるという問題が1つあります。

https://github.com/texane/stlink/blob/0082e488579077762627dba2cee54ffca64dad17/src/gdbserver/gdb-server.c#L1121

この関数呼び出しは、while（1）ループを終了するための適切な値を返しません。 問題は、関数またはwhile（1）メカニズムの内部にある可能性があります。

lldbでエラー処理プロセスを確認した後、おそらく障害コードを見つけました。

https://github.com/texane/stlink/blob/bf840a1ae82ffc3ef9929f243bb8050d6856f698/src/gdbserver/gdb-server.c#L1448

_stlink_usb_stepで、libusb呼び出しの失敗によって最初にトリガーされたエラーが発生すると、ゼロ以外の戻り値（この場合は-1）が返されます。 ただし、この戻り値は、gdb-serverのrecv-handle-sendループでは処理されません。

https://github.com/texane/stlink/blob/bf840a1ae82ffc3ef9929f243bb8050d6856f698/src/gdbserver/gdb-server.c#L1119

私は2つの可能な取引戦略を考え出します：

共通部分：スイッチケースのstlink_stepの戻り値を確認します。

1. エラーが表示された場合は、GDBに通知して終了してください。
2. 制限された時間にこの関数呼び出しをやり直します。失敗が続く場合は、GDBに通知して終了します。それ以外の場合は、続行します。

分析：

通信エラーの後に何が起こるかを予測できないため、オプション1は受け入れられます。 欠点は、st-utilが不安定なUSBポートなどでより頻繁に失敗する可能性があることです。
オプション2は、不安定なデバイスに別の機会を与えますが、パケットの重複を引き起こす可能性があり、デバッグが少し予測不可能になります。

詳細な分析のためのThx。 ここではオプション1を優先します。 特定のローカルハードウェアの不安定性に関連する問題が発生した場合、とにかくそれに対して私たちができることは何もありません。また、これはstlinkツールが考慮すべきことでもありません。 デバッグに関して妥協することがより重要であるように思われます。 これをすぐに修正できますか？

パケットを正しく送信するためにgdbのドキュメントを確認します。 それほど難しいことではないと思います。
終わったらPRを上げます。

私はそれを言いませんでした、しかし私はオプション2に行きました。しかしあなたの説明の後：あなたは正しいです。 エラーが一時的なものであると信じる正当な理由がない限り、エラーはすぐに致命的であると見なされるべきです。

ユーザーに通知せずに再試行すると、突然の驚きにつながります。 転送されたビットの1/100または1/1000が（どのレベルでも）破損したとします。 その結果、99％の確率でコマンドが「無効」になった場合、その状況のユーザーは、問題を引き起こすサイレントデータの破損を取得する前に、ハードウェアが不安定であるという警告を平均してたくさん受け取ります（つまり、突然終了します）。 ..。。

「簡単な方法」は、単に「（）を終了する」ことです。 これにより、gdbへの接続が突然閉じられ、十分に正常に処理されます。

基本的な機能は、stm32f401ボードを使用したPRで適切に実行されます。
デッドループは、ローカルテスト中に解決されました。 これで、st-utilが終了します。 gdbは失敗応答を受け取り、切断します。