توقف نقطة نهاية USB ومهلة نقل Bulk: قراءة الالتقاط قبل تغيير البرامج الثابتة
كيفية تصحيح أخطاء توقف نقطة نهاية USB، ومهلات نقل bulk، وحالات فشل مسار بيانات جانب البرامج الثابتة باستخدام أدلة النقل.
بعد نجاح التعداد، لا تزال أجهزة USB تفشل بطرق تبدو غامضة لمطوري التطبيقات: "تنتهي مهلات قراءات bulk، ولا تكتمل الكتابات أبدًا، وتتوقف تقارير HID، أو يُبلغ المضيف عن STALL نقطة نهاية. غالبًا ما تُعامل هذه حالات الفشل كأخطاء برنامج تشغيل أو توقفات عشوائية للبرامج الثابتة. يمكن أن يضيّق الالتقاط عادة المشكلة بشكل أسرع."
حالات فشل نقطة النهاية هي أدلة مسار البيانات. تحدث بعد أن تعلم المضيف شكل الجهاز. هذا يعني أن الواصفات قد تكون صحيحة بينما يظل سلوك نقطة النهاية خاطئًا.
STALL إشارة وليس مجرد خطأ
يمكن لنقطة نهاية USB أن تُرجع STALL للإشارة إلى أنها لا تستطيع معالجة طلب أو أن أمر فئة/بائع غير مدعوم. يمكن أن تكون توقفات نقطة نهاية التحكم أثناء طلبات الفئة مشروعة إذا كان الطلب غير صالح. تحتاج توقفات نقطة نهاية البيانات أثناء تدفق النقل العادي عادةً إلى فحص أقرب.
أسئلة الالتقاط:
- أي نقطة نهاية توقفت؟
- هل كانت تحكمًا أم bulk أم interrupt أم isochronous؟
- ما الطلب أو النقل الذي سبق التوقف؟
- هل مسح المضيف حالة التوقف؟
- هل استؤنفت الحركة بعد
CLEAR_FEATURE(ENDPOINT_HALT)؟ - هل أوقفت البرامج الثابتة عن قصد الأوامر غير المدعومة؟
بدون هذا السياق، "نقطة نهاية متوقفة" غامضة جدًا بحيث لا يمكن التصرف بناءً عليها.
مهلات Bulk تحتاج سياق الاتجاه والطابور
يمكن أن تعني مهلة نقل bulk أشياء كثيرة:
- توقع المضيف بيانات IN لكن الجهاز لم يكن لديه
- توقع الجهاز بيانات OUT لكن التطبيق توقف عن الكتابة
- لم يكن مخزن نقطة نهاية البرامج الثابتة جاهزًا
- قدم برنامج تشغيل المضيف قراءة أكبر مما يدعمه سلوك البرامج الثابتة
- NAK الجهاز حتى المهلة
- عنوان نقطة النهاية أو الاتجاه كان خاطئًا
- لم يُمسح التوقف السابق أبدًا
أول شيء يجب فحصه هو الاتجاه. مهلة bulk IN ومهلة bulk OUT حالتان مختلفتان. بالنسبة لـ IN، اسأل ما إذا كان الجهاز قد أعاد البيانات أبدًا. بالنسبة لـ OUT، اسأل ما إذا كان المضيف قد أرسل البيانات وما إذا كان الجهاز قد أكدها.
صحة الواصفات ضرورية لكنها غير كافية
يمكن أن يعلن واصف نقطة نهاية bulk IN بشكل صحيح، ولا يزال الجهاز يفشل في إرسال بيانات مفيدة. يمكن لجهاز CDC أن يعد كمنفذ تسلسلي ولا يزال يتجاهل ترميز الخط أو حالة خط التحكم. يمكن لواجهة خاصة بالبائع أن تكشف نقاط نهاية لكنها تتطلب أمر تهيئة قبل حركة البيانات.
هذا يعني أن تصحيح أخطاء نقطة النهاية يجب أن يجمع:
- أدلة الواصف
- طلبات إعداد الفئة أو البائع
- اتجاه النقل
- طول الحمولة
- نتيجة الحالة
- التوقيت والمحاولات المتكررة
يجب أن يُظهر الالتقاط ما إذا كان المضيف يطلب شيئًا غير معقول أو البرامج الثابتة لا تفي بطلب صالح.
يجب على فرق البرامج الثابتة الالتقاط قبل وبعد الإصلاح
لأخطاء نقطة النهاية، تكون الالتقاطات قبل وبعد ذات قيمة. يثبت الالتقاط الأول الفشل. يثبت الالتقاط الثاني الإصلاح. تُظهر المقارنة الجيدة:
- نفس الجهاز والتهيئة
- نفس عناوين نقطة النهاية
- نفس نمط طلب المضيف
- الالتقاط القديم يتوقف أو تنتهي مهلته
- الالتقاط الجديد يكمل ويحمل الحمولة المتوقعة
هذا يجعل مراجعة انحدار البرامج الثابتة أسهل بكثير. كما أنه يعطي فرق الدعم قطعة أثر قابلة للتكرار عندما يُبلغ العملاء أن "USB يتجمد عشوائيًا".
أين يتناسب Bus Scope
يهدف Bus Scope إلى أدلة USB، وليس انتشار بروتوكول عام. لحالات توقف نقطة النهاية والمهلة، يجب أن يحافظ على تفاصيل الحزمة، وبيانات نقطة النهاية الوصفية، والبايتات الخام، ونوع النقل، وتفسير الفئة قريبًا معًا.
الناتج المفيد هو:
- نقطة النهاية والاتجاه
- نوع النقل
- الطلب أو النقل قبل الفشل
- أدلة الحالة
- الحمولة الخام حول الفشل
- ما إذا كانت المشكلة تتبع التعداد، أو إعداد الفئة، أو حركة التطبيق
هذه هي المعلومات التي يحتاجها مهندسو البرامج الثابتة قبل لمس منطق مخزن نقطة النهاية المؤقت أو سلوك إعادة محاولة جانب المضيف.
إذا كان استعلام البحث الخاص بك هو "مهلة نقل bulk USB" أو "نقطة نهاية USB متوقفة"، فلا تبدأ بإعادة كتابة مكدس الجهاز بالكامل. التقط أدلة نقطة النهاية أولاً.