تصحيح أخطاء DTR وRTS لـ USB CDC ACM: SetControlLineState وفتحات المنفذ التسلسلي وإعادة تعيين Bootloader

تبدو أجهزة USB CDC ACM مثل المنافذ التسلسلية، لكن العديد من أخطاء "المنفذ التسلسلي" هي في الواقع أخطاء تحكم فئة USB. يبحث المستخدمون عن "CDC ACM DTR RTS"، و"SetControlLineState USB"، و"USB serial no data until DTR"، و"Arduino resets when serial port opens"، و"USB CDC bootloader reset"، و"COM port opens but device does not respond" عندما يكون المنفذ موجودًا لكن السلوك خاطئ.

يكون Bus Scope مفيدًا لأن DTR وRTS ليسا أعلام تطبيق سحرية. يرسل المضيف طلبات تحكم خاصة بالفئة، وتتفاعل البرامج الثابتة مع تلك الطلبات.

ماذا تفعل SetControlLineState

يستخدم CDC ACM طلب فئة يُسمى عادةً SetControlLineState. يتواصل حالة خط التحكم مثل:

• DTR: جاهزية محطة البيانات.
• RTS: طلب الإرسال.

تستخدم العديد من الأجهزة هذه البتات لأكثر من سلوك المودم التقليدي. قد تبدأ البرامج الثابتة البث فقط بعد تأكيد DTR، أو تدخل bootloader عند تبديل DTR، أو تستخدم RTS لدلالات التحكم في التدفق.

الأعراض الشائعة

تظهر مشكلات خط التحكم كـ:

• يفتح منفذ COM لكن لا تصل بيانات.
• يبدأ الجهاز في الإرسال فقط بعد اتصال برنامج المحطة الطرفية.
• تعيد البرامج الثابتة ضبطها عند فتح مراقب تسلسلي.
• يظهر bootloader بعد فتح/إغلاق المنفذ.
• تتوقف البيانات عند انخفاض DTR.
• تغيير خيار التحكم في التدفق RTS/CTS للسلوك.
• أداة Linux تعمل لكن أداة Windows لا تعمل.
• سلوك نص Python مختلف عن محاكي الطرفية.

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

سلوك فتح المنفذ التسلسلي

تضع تطبيقات المضيف المختلفة DTR وRTS بشكل مختلف عند فتح منفذ.

أمثلة:

• يؤكد محاكي الطرفية DTR فورًا.
• يفتح البرنامج النصي المنفذ لكن يترك DTR خطأ.
• أداة تحديث البرامج الثابتة تبدل DTR كإشارة إعادة تعيين.
• يعين برنامج التشغيل RTS بناءً على إعدادات التحكم في التدفق.
• يغلق التطبيق المنفذ ويسقط DTR بشكل غير متوقع.

يمكن أن يُظهر تتبع الحزم تسلسل طلب التحكم الفعلي بدلاً من الاعتماد على افتراضات التطبيق.

أنماط إعادة تعيين Bootloader

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

أنماط الفشل:

• يعيد الجهاز الضبط في كل مرة يفتح فيها عارض السجلات.
• يعمل تحميل البرامج الثابتة لكن الاتصال التسلسلي العادي يفشل.
• يظهر الجهاز كهوية USB واحدة، يعيد الضبط، ثم يعد كـ bootloader.
• يتغير الرقم التسلسلي أو سلسلة المنتج بعد إعادة الضبط.
• يفقد التطبيق مقبض المنفذ.

يجب أن يحافظ Bus Scope على طلب التحكم وتسلسل إعادة التعداد.

لا توجد بيانات حتى DTR

تنتظر بعض البرامج الثابتة عمدًا DTR قبل إرسال البيانات. يمكن أن يجعل هذا أداة واحدة تبدو معطلة بينما تعمل أخرى.

الأدلة:

• يفتح المضيف نقاط نهاية bulk أو interrupt.
• لم يتم إرسال بيانات IN.
• يرسل المضيف SetControlLineState مع DTR true.
• يبدأ الجهاز في الإرسال.

هذه ليست مشكلة كابل وليست بالضرورة خطأ برنامج تشغيل. إنها سياسة البرامج الثابتة.

ارتباك RTS والتحكم في التدفق

قد يُستخدم RTS للتحكم في التدفق للأجهزة، لكن العديد من أجهزة USB CDC ليس لديها خطوط مودم حقيقية. قد لا تزال البرامج الثابتة تعرض حالة RTS لمنطق التطبيق.

الأسئلة:

• هل يحدد المضيف RTS؟
• هل يتطلب الجهاز RTS قبل الإرسال؟
• هل تغيير تمكين التحكم في التدفق للأجهزة في الطرفية يغير بتات الطلب؟
• هل تتجاهل البرامج الثابتة RTS لكن الوثائق تدعي خلاف ذلك؟
• هل يُستخدم RTS كإشارة bootloader أو تحديد الوضع؟

تمنع أدلة الحزم التخمين.

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

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

1. التقط التعداد.
2. افتح المنفذ التسلسلي مع التطبيق الفاشل.
3. سجّل طلبات CDC الخاصة بالفئة.
4. ابحث عن SetControlLineState.
5. فك تشفير بتات DTR وRTS.
6. قارن مع برنامج طرفية عامل.
7. تحقق مما إذا كانت البيانات تبدأ بعد DTR.
8. تحقق مما إذا كانت إعادة الضبط أو إعادة التعداد تتبع تبديلًا.
9. قارن أدوات Windows وLinux.
10. حافظ على طلبات التحكم وحزم البيانات الأولى معًا.

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

مشكلات DTR وRTS لـ USB CDC ACM هي مشكلات تسلسل تحكم فئة. قد يوجد المنفذ وقد يربط برامج التشغيل بشكل صحيح بينما تنتظر البرامج الثابتة حالة خط تحكم لا يرسلها التطبيق أبدًا.

يساعد Bus Scope في إظهار SetControlLineState وDTR وRTS وسلوك الفتح التسلسلي وإعادة تعيين bootloader وأسباب البيانات المفقودة على مستوى بروتوكول USB.