استعادة توقف نقطة نهاية USB: CLEAR_FEATURE وحلقات STALL وحالات فشل Bulk وسلوك إعادة ضبط برنامج التشغيل

توقفات نقطة نهاية USB هي مصدر شائع لأخطاء الأجهزة التي "تعمل مرة ثم تفشل". يتوقف نقل bulk، ويمسح برنامج التشغيل التوقف، ويتوقف الجهاز مرة أخرى، وفي النهاية يُبلغ التطبيق عن مهلة أو خطأ إدخال/إخراج أو إعادة ضبط الجهاز أو فصله. يبحث المستخدمون عن "توقف نقطة نهاية USB"، و"CLEAR_FEATURE ENDPOINT_HALT"، و"حلقة توقف USB"، و"نقطة نهاية bulk متوقفة"، و"libusb clear halt" عندما لا يختفي الجهاز ببساطة بل يتوقف عن قبول الحركة على نقطة نهاية محددة.

يكون Bus Scope مفيدًا لأن استعادة توقف نقطة النهاية هي تسلسل، وليس حدثًا واحدًا. تحتاج إلى رؤية أول توقف، وطلب استعادة المضيف، وما فعله الجهاز بعد ذلك، وما إذا كان نفس الأمر تسبب في التوقف مرة أخرى.

ما يعنيه توقف نقطة النهاية

توقف نقطة النهاية يعني أن نقطة النهاية متوقفة ولا يمكنها متابعة عمليات النقل العادية حتى يتم مسح حالة التوقف. قد يصدر المضيف:

CLEAR_FEATURE(ENDPOINT_HALT)

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

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

STALL مقابل المهلة

STALL صريح. المهلة تعني عدم اكتمال في الوقت المتوقع. قد تحدث المهلة لأن نقطة النهاية لم تستجب أبدًا، أو أن الجهاز استمر في NAK، أو أن الجهاز انفصل.

تبدأ استعادة توقف نقطة النهاية بـ STALL. إذا لم يرَ المضيف أبدًا STALL ورأى فقط مهلة، فإن مسار الاستعادة مختلف.

توقف نقطة نهاية Bulk

تتوقف نقاط نهاية Bulk غالبًا عندما يكون الأمر غير صالح، أو مرحلة البروتوكول خاطئة، أو اكتشفت البرامج الثابتة خطأ.

مثال:

Host -> Device bulk OUT command
Device -> Host STALL on bulk IN
Host -> Device CLEAR_FEATURE(ENDPOINT_HALT)
Host retries bulk IN
Device stalls again

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

يجب أن تتطابق الاستعادة مع اتجاه نقطة النهاية

تتضمن عناوين نقطة النهاية الاتجاه. نقطة النهاية 0x81 ونقطة النهاية 0x01 اتجاهات مختلفة. مسح نقطة النهاية الخاطئة لن يستعيد الأنبوب المتوقف.

تحقق من:

• أي نقطة نهاية توقفت؟
• الاتجاه IN أم OUT؟
• هل مسح المضيف نفس نقطة النهاية؟
• هل استؤنفت عمليات النقل بعد المسح؟
• هل استعادت حالة تبديل البيانات/الحالة بشكل صحيح؟

هذا مصدر شائع لتقارير "لم ينجح مسح التوقف" المضللة.

حلقات STALL المتكررة

يعني STALL المتكرر بعد المسح عادة أن السبب الأساسي لا يزال موجودًا:

• يرسل المضيف أمرًا غير مدعوم مرة أخرى.
• تبقى آلة حالة البرامج الثابتة في الخطأ.
• الجهاز يتوقع إعادة الضبط قبل إعادة المحاولة.
• يقرأ المضيف من نقطة النهاية الخاطئة.
• طول الأمر أو المجموع الاختباري خاطئ.
• حالة تبديل بيانات نقطة النهاية/الحالة غير متسقة.
• تتطلب البرامج الثابتة طلب فئة/بائع قبل الاستئناف.

يجب أن يتضمن التتبع الأمر قبل أول STALL، وليس فقط محاولات الاستعادة.

سلوك إعادة ضبط برنامج التشغيل

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

حافظ على الخط الزمني:

1. آخر أمر ناجح.
2. أول STALL.
3. محاولة مسح التوقف.
4. إعادة المحاولة.
5. STALL أو مهلة متكررة.
6. إعادة ضبط الجهاز أو فصله.

قائمة مراجعة التصحيح

استخدم سير العمل هذا:

1. حدد نقطة النهاية التي توقفت.
2. سجّل اتجاه نقطة النهاية ونوع النقل.
3. افحص الأمر أو النقل فورًا قبل STALL.
4. تحقق مما إذا كان المضيف يرسل CLEAR_FEATURE(ENDPOINT_HALT).
5. تأكد من أنه يستهدف نقطة النهاية الصحيحة.
6. تحقق مما إذا كان النقل يستأنف.
7. إذا تكرر STALL، افحص حالة بروتوكول البرامج الثابتة.
8. ابحث عن إعادة ضبط الجهاز بعد فشل الاستعادة.
9. قارن بتسلسل أوامر معروف جيدًا.
10. حافظ على سياق كافٍ قبل STALL.

التشخيص النهائي

استعادة توقف نقطة نهاية USB هي مشكلة آلة حالة. يمكن لـ CLEAR_FEATURE(ENDPOINT_HALT) مسح حالة نقطة نهاية USB، لكنه لا يصلح تلقائيًا حالة بروتوكول البرامج الثابتة، أو الأوامر غير الصالحة، أو نقاط النهاية الخاطئة، أو منطق إعادة محاولة برنامج التشغيل.

يساعد Bus Scope في كشف تسلسل التوقف والاستعادة الكامل بحيث يمكن تشخيص حالات فشل نقطة النهاية من سلوك USB الفعلي.