Stlink: st-util은 LIBUSB_ERROR_NO_DEVICE에서 종료되어야 합니다.

stlink 는 이 시점에서 종료되어야 한다고 생각합니다. https://github.com/texane/stlink/blob/df3c2b02867db03fb82f6faaad71300398965e85/src/usb.c#L54

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는 그 일부이며 라이브러리에서 종료를 사용해서는 안 됨) 라이브러리의 파일은 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 명령을 실행

패킷 송수신을 무제한으로 재시도하지 않고 프로그램을 종료해야 하는 한 가지 문제가 있습니다.

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 호출 실패로 인해 처음에 발생한 오류가 발생하면 0이 아닌 반환 값(이 경우 -1)을 반환합니다. 그러나 이 반환 값은 gdb-server의 recv-handle-send 루프에 의해 처리되지 않습니다.

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

두 가지 가능한 거래 전략을 제시합니다.

공통 부분: 스위치 케이스에서 stlink_step 의 반환 값을 확인하십시오.

1. 오류가 표시되면 GDB에 알리고 종료하십시오.
2. 제한된 시간 동안 이 함수 호출을 다시 실행하고, 실패가 남아 있으면 GDB에 알리고 종료하고, 그렇지 않으면 계속 진행합니다.

분석:

옵션 1은 통신 오류 후에 어떤 일이 일어날지 예측할 수 없기 때문에 허용됩니다. 단점은 st-util이 일부 불안정한 USB 포트 또는 이와 유사한 포트에서 더 자주 실패할 수 있다는 것입니다.
옵션 2는 불안정한 장치에 또 다른 기회를 제공하지만 패킷 복제를 일으킬 수 있어 디버깅을 약간 더 예측할 수 없게 만듭니다.

자세한 분석을 위해 Thx. 저는 여기에서 옵션 1을 선호합니다. 사람들이 특정 로컬 하드웨어 불안정과 관련된 문제에 직면하면 어쨌든 우리가 할 수 있는 일은 없으며 stlink 도구가 고려해야 할 사항도 아닙니다. 디버깅에 대해 타협을 하는 것이 더 중요해 보입니다. 이것을 바로 고칠 수 있습니까?

패킷을 제대로 보내기 위해 gdb 문서를 확인하겠습니다. 너무 어렵지 않은 것 같아요.
끝나면 PR 올리겠습니다.

나는 말하지 않았지만 옵션 2를 선택하려고했습니다. 그러나 당신의 설명 후에 : 당신이 옳습니다. 오류가 일시적이라고 믿을 만한 타당한 이유가 없는 한 오류는 즉시 치명적인 오류로 간주되어야 합니다.

사용자에게 알리지 않고 재시도하면 갑작스러운 놀라움이 발생할 수 있습니다. 전송된 비트의 1/100 또는 1/1000(레벨에 관계없이)이 손상되었다고 가정합니다. 그 결과 99%의 시간 동안 명령이 "유효하지 않음"이 되는 경우 해당 상황의 사용자는 문제를 일으키는 자동 데이터 손상을 받기 전에 하드웨어가 불안정하다는 경고(즉, 갑자기 종료되는 stlink)를 평균적으로 많이 받게 됩니다. ...

"쉬운 탈출구"는 "exit()"입니다. 그러면 갑자기 gdb에 대한 연결이 닫히고 충분히 우아하게 처리됩니다.

기본 기능은 stm32f401 보드가 있는 PR에서 잘 실행됩니다.
데드 루프는 로컬 테스트 중에 해결됩니다. 이제 st-util이 종료됩니다. gdb는 실패 응답을 수신하고 연결을 끊습니다.