Stlink: يجب أن يتم الخروج من st-util في LIBUSB_ERROR_NO_DEVICE

تم إنشاؤها على ١٧ مارس ٢٠١٩  ·  12تعليقات  ·  مصدر: stlink-org/stlink

عندما أقوم بفصل مصحح أخطاء USB لأول مرة ثم أحاول إصدار أمر عبر GDB ، فإن st-util يعطي الأخطاء التالية بسرعة كبيرة:

  core status: unknown
[!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE                      
[!] send_recv STLINK_DEBUG_GETSTATUS
  core status: unknown
[!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE                      
[!] send_recv STLINK_DEBUG_GETSTATUS
  core status: unknown
[!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE                      
[!] send_recv STLINK_DEBUG_GETSTATUS
  core status: unknown
[!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE                      
[!] send_recv STLINK_DEBUG_GETSTATUS
  core status: unknown
2019-03-17T14:26:42 ERROR src/flash_loader.c: flash loader run error           
2019-03-17T14:26:42 ERROR src/common.c: stlink_flash_loader_run(0x8000000) failed! == -1

وبالتالي تحتل وحدة المعالجة المركزية ما يقرب من 100٪. ينتج عن هذا إهدار كبير للوقت (إعادة تشغيل الجهاز الظاهري ، وما إلى ذلك).

نوع رسالة الخطأ أمر طبيعي تمامًا. ومع ذلك ، يجب الخروج من stutil فورًا عند حدوث هذا الخطأ حتى أتمكن من معالجة بقية المشكلة عن طريق إعادة تشغيل stutil أو اتخاذ بعض الإجراءات الأخرى.

bufixed componenst-util componenstlink-lib dependenclibusb errogdb-server staturesolved
مصدر
picture ceremcem

ال 12 كومينتر

أعتقد أن stlink يجب أن ينتهي عند هذه النقطة: https://github.com/texane/stlink/blob/df3c2b02867db03fb82f6faaad71300398965e85/src/usb.c#L54

ceremcem picture ceremcem في ٢٥ يونيو ٢٠١٩

أعتقد أن stlink يجب أن ينتهي عند هذه النقطة:

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

نعم ، أعتقد أنك على حق ، يجب التحقق من المكالمة إلى libusb بشكل مناسب. إذا كنت تريد يمكنك التصحيح وإرسال العلاقات العامة. يجب أن يتم ذلك أيضًا للمكالمات الأخرى إلى libusb في ملف usb.c. شكرا على الإبلاغ!

xor-gate picture xor-gate في ٢٥ يونيو ٢٠١٩

إذا كنت تريد يمكنك التصحيح وإرسال العلاقات العامة.

أحب أن. ومع ذلك ، لست متأكدًا من أنني أفهم هيكل المشروع ، لذا يكفي exit(1) هنا أم لا.

يجب أن يتم ذلك أيضًا للمكالمات الأخرى إلى libusb في ملف usb.c.

قد لا أفهم هذا جيدًا. هل تقصد " send_recv اجعل التطبيق ينتهي أينما كان يُرجع -1 "؟

ceremcem picture ceremcem في ٢٥ يونيو ٢٠١٩

لقد وضعت تعليقًا في العلاقات العامة ، هناك المزيد من الأماكن حيث يمكن أن يحدث خطأ عند إجراء مكالمات إلى 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
xor-gate picture xor-gate في ٢٦ يونيو ٢٠١٩

أعتقد أن هذا قد يكون مرتبطًا بالرقمين 888 و 445.
ceremcem و rewolff : ماذا عن فكرة مناقشة هذا معًا؟

Nightwalker-87 picture Nightwalker-87 في ٢٧ مارس ٢٠٢٠

chenguokai : هل لديك فكرة عن كيفية المضي قدما هنا؟

Nightwalker-87 picture Nightwalker-87 في ٧ أبريل ٢٠٢٠

لا يمكن إعادة إنتاج هذه الحالة.
لقد اتبعت الإجراء على جهاز macOS الخاص بي. تظهر رسالة الخطأ ، ولكن لا توجد علامة على إدخال أي حلقات ميتة.
image
image

تحرير: لقد أصدرت الأمر n بعد إعداد نقطة توقف على وظيفة main وإلغاء توصيل st-link

توجد مشكلة واحدة يجب على البرنامج الخروج منها بدلاً من إعادة محاولة إرسال الحزم أو استقبالها بشكل غير محدود.

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

لا يقوم استدعاء الوظيفة هذا بإرجاع قيمة مناسبة لإنهاء حلقة while (1). قد تكمن المشاكل داخل الوظيفة أو آلية while (1).

chenguokai picture chenguokai في ٨ أبريل ٢٠٢٠

بعد التحقق من عملية معالجة الخطأ باستخدام lldb ، ربما اكتشفت رمز الخطأ.

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

عندما يواجه _stlink_usb_step خطأ بدأ في البداية بسبب فشل استدعاء libusb ، فإنه يُرجع قيمة إرجاع غير صفرية (-1 في هذه الحالة). ومع ذلك ، لا تتم معالجة هذه القيمة المعادة من خلال حلقة recv-handle-send في خادم gdb:

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

لقد توصلت إلى استراتيجيتين محتملتين للصفقة:

الجزء المشترك: تحقق من قيمة الإرجاع stlink_step في حالة التبديل.

  1. في حالة ظهور أي خطأ ، حاول إخطار GDB والخروج.
  2. أعد استدعاء هذه الوظيفة لأوقات محددة ، إذا استمر الفشل ، أبلغ GDB واخرج ، وإلا فتابع.

تحليل:

الخيار 1 مقبول لأننا لا نستطيع التنبؤ بما سيحدث بعد حدوث خطأ في الاتصال. العيب هو أن st-use قد يفشل بشكل متكرر في بعض منافذ USB غير المستقرة أو شيء مشابه.
سيعطي الخيار 2 للأجهزة غير المستقرة فرصة أخرى ولكنه قد يتسبب في تكرار الحزمة ، مما يجعل تصحيح الأخطاء أكثر صعوبة إلى حد ما.

chenguokai picture chenguokai في ٨ أبريل ٢٠٢٠
🚀1

Thx لتحليل مفصل. أفضل الخيار 1 هنا. إذا واجه الأشخاص مشكلات تتعلق بعدم استقرار الأجهزة المحلية المحددة ، فلا يوجد شيء يمكننا القيام به على أي حال ، وهذا أيضًا ما يجب أن تضعه أدوات stlink في الاعتبار. يبدو أنه من المهم أن نقدم أي حل وسط بشأن تصحيح الأخطاء. هل أنت قادر على إصلاح هذا على الفور؟

Nightwalker-87 picture Nightwalker-87 في ٨ أبريل ٢٠٢٠

سوف أتحقق من وثائق gdb لإرسال الحزم (الحزم) بشكل صحيح. ليس من الصعب جدا على ما أعتقد.
بعد أن أنتهي ، سأرفع العلاقات العامة.

chenguokai picture chenguokai في ٨ أبريل ٢٠٢٠
👍1

لم أقل ذلك ، لكنني كنت أذهب للخيار 2. ولكن بعد توضيحك: أنت على حق. لقد جعلتني مقتنعًا: ما لم يكن هناك سبب وجيه للاعتقاد بأن الخطأ مؤقت ، يجب اعتبار الخطأ قاتلًا على الفور.

ستؤدي إعادة المحاولة دون إعلام المستخدم إلى حدوث مفاجآت مفاجئة. افترض أن 1/100 أو 1/1000 من البتات المنقولة تالفة (على أي مستوى). إذا أدى ذلك إلى أن يكون الأمر "غير صالح" في 99٪ من الوقت ، فإن المستخدم في هذه الحالة سيحصل في المتوسط ​​على تحذيرات كثيرة (مثل إنهاء stlink فجأة) بأن أجهزته غير مستقرة قبل أن يحصل على تلف البيانات الصامت الذي يسبب المشاكل. ...

"المخرج السهل" هو مجرد "الخروج ()". سيؤدي ذلك فجأة إلى إغلاق الاتصال بـ gdb وسيعالج ذلك بأمان كافٍ.

rewolff picture rewolff في ٨ أبريل ٢٠٢٠

تعمل الوظائف الأساسية بشكل جيد ضمن العلاقات العامة مع لوحة stm32f401.
تم حل الحلقة الميتة أثناء الاختبار المحلي الخاص بي. الآن ستخرج St-util. سيتلقى gdb ردًا على الإخفاق وقطع الاتصال.

chenguokai picture chenguokai في ٨ أبريل ٢٠٢٠
👍1
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

WRansohoff picture WRansohoff  ·  14تعليقات
grzegorz-kraszewski picture grzegorz-kraszewski  ·  9تعليقات
chenguokai picture chenguokai  ·  6تعليقات
lulle2007200 picture lulle2007200  ·  12تعليقات
xor-gate picture xor-gate  ·  7تعليقات