تصحيح أخطاء واصفات USB لأجهزة HID وCDC
كيف يمكن لفرق البرامج الثابتة تشخيص أجهزة USB HID وCDC من خلال فحص أدلة الواصفات والنقل بدلاً من التخمين من أخطاء برنامج التشغيل.
أجهزة HID وCDC شائعة لأنها تتيح لفرق البرامج الثابتة شحن واجهات USB مفيدة دون كتابة برنامج تشغيل مخصص لكل مضيف. تعتمد هذه الراحة على دقة الواصفات. عندما تفشل لوحة مفاتيح HID أو جهاز استشعار أو جسر تسلسلي أو جهاز مركب، غالبًا ما يكون السبب الجذري مرئيًا في أدلة الواصفات قبل أن يظهر في التطبيق.
تصحيح أخطاء الواصفات ليس مبهرجًا، لكنه واحد من أسرع الطرق لحل حالات دعم USB.
HID: واصف التقرير هو العقد
بالنسبة لأجهزة HID، يحتاج المضيف إلى أكثر من معلومات نقطة النهاية. يحتاج إلى واصف تقرير HID. يحدد هذا الواصف معرّفات التقارير والاستخدامات والأحجام والعدد والنطاقات المنطقية وكيف يجب تفسير البايتات.
تشمل أخطاء HID الشائعة:
- طول التقرير لا يطابق حمولات المقاطعة الفعلية
- معرّف التقرير مستخدم في البرامج الثابتة لكن غير مُعلن بشكل متسق
- قيم الحد الأدنى والأقصى المنطقية لا تطابق تمثيل البيانات
- صفحة الاستخدام أو الاستخدام لا يطابق توقعات المضيف
- فاصل نقطة النهاية غير واقعي لسلوك الجهاز
- افتراضات بروتوكول التمهيد تتعارض مع سلوك بروتوكول التقرير
قد يبدو خطأ المضيف غامضًا. يمكن أن يجعل الالتقاط الذي يُظهر بايتات الواصف وعمليات نقل المقاطعة عدم التطابق واضحًا.
CDC: تخطيط الواجهة مهم
عادة ما تكشف أجهزة CDC ACM عن واجهة اتصال وواجهة بيانات. يتوقع المضيف مجموعة متماسكة من الواصفات والطلبات الخاصة بالفئة. يمكن أن يمنع واصف وظيفي مفقود، أو ربط واجهة خاطئ، أو عدم تطابق نقطة النهاية، ظهور منفذ تسلسلي افتراضي.
أدلة للفحص:
- فئة الواجهة والفئة الفرعية
- واصفات رأس CDC وACM والاتحاد وإدارة المكالمات
- نقطة نهاية الإشعار
- نقاط نهاية bulk IN وOUT
SET_LINE_CODINGSET_CONTROL_LINE_STATE- عمليات نقل البيانات بعد التهيئة
إذا ظهر المنفذ التسلسلي لكن لا تتحرك بايتات، فقد تكون المشكلة في سلوك نقطة النهاية أو بروتوكول التطبيق. إذا لم يظهر المنفذ التسلسلي أبدًا، فالواصفات وطلبات الفئة هي أول مكان للنظر.
الأجهزة المركبة تحتاج انضباطًا إضافيًا
يمكن أن تجمع الأجهزة المركبة بين HID وCDC وتخزين الكتلة والواجهات الخاصة بالبائع والمزيد. هذا مفيد، لكنه يضاعف أنماط الفشل. يمكن أن يؤثر خطأ واصف في واجهة واحدة على ربط المضيف للجهاز بأكمله.
لتصحيح أخطاء الأجهزة المركبة، افحص:
- الطول الكلي للتهيئة
- أرقام الواجهات
- واصفات ربط الواجهة
- تفرّد نقطة النهاية
- موضع الواصفات الخاصة بالفئة
- طلبات المضيف لكل واجهة
لا تفترض أن "البرامج الثابتة ترسل البايتات الصحيحة" حتى يثبت الالتقاط أن المضيف رأى البنية الصحيحة.
لماذا تهم كل من البايتات الخام وتفسير الفئة
البايتات الخام هي الحقيقة الأرضية. تفسير الفئة يجعلها قابلة للاستخدام. يجب أن تعرض أداة تشخيص USB الجيدة كليهما. يحتاج المهندسون إلى رؤية بايتات الواصفات الدقيقة عندما يكون هناك خطأ ما، لكنهم يحتاجون أيضًا إلى الحقول المفكوكة لتجنب عد الإزاحات يدويًا في كل حالة.
أفضل سير عمل هو:
- افحص شجرة الواصفات المفكوكة
- انتقل إلى البايتات الخام للحقول المشبوهة
- قارن طلبات المضيف باستجابات البرامج الثابتة
- افحص عمليات نقل نقطة النهاية بعد التهيئة
- احفظ الجلسة لإعادة الإنتاج أو تسليم الدعم
يحافظ سير العمل هذا على التشخيص مرتبطًا بالأدلة.
أين يتناسب Bus Scope
تم تصميم Bus Scope لفرق البرامج الثابتة والمختبرات المادية وبائعي الأجهزة الذين يحتاجون إلى إجابة قابلة للتكرار حول فشل حركة USB. يحافظ على سياق مستكشف الجهاز، وتفاصيل الحزمة، والبايتات الخام، والواصفات، وملاحظات الفئة، والمرشحات، وجلسات .bscope المحفوظة في منصة عمل واحدة.
لحالات HID وCDC، يجب أن يساعد Bus Scope في الإجابة:
- هل اكتمل التعداد؟
- هل طابقت الواصفات الفئة المقصودة؟
- هل أرسل المضيف طلبات الفئة المتوقعة؟
- هل طابقت عمليات نقل نقطة النهاية توقعات التقرير أو ترميز الخط؟
- هل هذه مشكلة في البرامج الثابتة أم برنامج تشغيل المضيف أم بروتوكول التطبيق؟
هذا هو الفرق بين رؤية "فشل برنامج التشغيل" وفهم أي عقد USB تم كسره.