في حالة عدم وجود هدف متصل حاليًا ، يتم العثور على المبرمج ولكن لا يتم عرض مسلسل. هذا ليس مفيدًا عندما نستخرج الرقم التسلسلي (و OpenOCD hla_serial
) عند تشغيل الهدف.
grevaillot : لقد فزت للتو بهذه التذكرة ، لأنني وجدت أن الالتزام 804c38ead8aef3e4a1640a82a9b9c01f4f60eed1 يبدو بطريقة ما أنه يعالج المشكلة أعلاه (لكل حادث؟) أجد مبرمج STlink-v2 الخاص بي يتصرف بشكل مختلف منذ (بالضبط) هذا الالتزام. لا أعرف حقًا ما الذي يسبب هذا التغيير.
هنا ناتج st-info --probe
إذا لم يتم توصيل أي جهاز بالمبرمج:
قبل:
Found 1 stlink programmers
عقب ذلك مباشرة:
Found 1 stlink programmers
serial: 3f76050132124647524b4e00
hla-serial: "\x3f\x76\x05\x01\x32\x12\x46\x47\x52\x4b\x4e\x00"
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0000
descr: unknown device
لا أفهم حقًا سبب حدوث ذلك.
ومع ذلك ، بما أنك المؤلف ، فمن المنطقي السماح لك بإلقاء نظرة على هذا.
لم أكن على علم بهذه التذكرة ، لكن نعم ، هذا مقصود. لدي بعض الإصلاحات لخادم st-flash و gdb للدفع إلى مسبار USB لإرجاع بعض معلومات st-link دون أي هدف متصل ، وسأضع علامة عليها برقم التذكرة.
حسنًا ، الالتزام الذي أشرت إليه ليس جيدًا ، لقد تم إصلاحه في مجموعة التصحيح الخاصة بإعادة صياغة المسبار
grevaillot لا أعرف حقًا ما الذي يسبب التغيير الملحوظ هناك بعد ذلك. ربما يكون إصلاحًا جزئيًا فقط هو الذي يؤدي إلى التغيير مع هذا الجهاز أو فقط عدد قليل من الأجهزة الأخرى كما هو واضح من جانب الكود ، ولكنه ليس إصلاحًا كاملاً يعالج جميع الأجهزة بحلول ذلك الوقت - لا يوجد دليل على ذلك حتى الآن. سأحاول مبرمجي الثاني مع هذا الالتزام أيضًا (قبل وبعد). كلاهما من الأجهزة CKS32F103C8T6.
هنا ناتج st-info --probe
مع الالتزام 804c38ead8aef3e4a1640a82a9b9c01f4f60eed1 للمبرمج الثاني ، والذي يبدو أنه نفس النتيجة:
Found 1 stlink programmers
serial: 3f70050132124647524b4e00
hla-serial: "\x3f\x70\x05\x01\x32\x12\x46\x47\x52\x4b\x4e\x00"
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0000
descr: unknown device
بينما يُرجع الالتزام السابق 46bf0abf77cca47133d3839460cc7679e0f78714:
Found 1 stlink programmers
ما زلت أتساءل لماذا ...
آسف ، لقد تاهت في شجرتى ، دعنا نلخص:
وسيط يلتزم بأشياء إعادة صياغة المسبار يمكن أن يسمح بالحصول على بعض stlink مع عدم وجود هدف متصل لإظهار أنه "تم العثور على مبرمج واحد stlink" بدون تسلسل. كانت هذه مشكلة ، وكان المسبار يعيد عدد stlink الموجود بدلاً من عدد stlink الذي تم فحصه.
لا يمكن لـ 804c38ead8aef3e4a1640a82a9b9c01f4f60eed1 بأي حال من الأحوال تغيير سلوك المجس ، وأظن أن بعض مشكلات إعادة البناء والاختبار المحلية غير النظيفة :)
العلاقات العامة الخاصة بي https://github.com/stlink-org/stlink/pull/933 يجب أن تغلق هذه المشكلة.
راجع للشغل ، أعتقد أنه ربما يجب أن تعرض مكالمة الاختبار cpuid. يجب ألا يكون هذا العنصر فارغًا أبدًا وسيساعد في تقرير دعم / خطأ جديد للرقاقة. لكن هذه مشكلة أخرى.
grevaillot : أنت محق في أنها لا بد أنها كانت عملية إعادة بناء محلية غير نظيفة: لقد اكتشفت الآن أن النتائج التي توصلت إليها مستمدة من التغييرات التي أدخلتها عملية الدمج اليدوي الأقدم aad5cf1901f467914a2efe855c0caff7fdf99048 ، وبالتالي لا شيء من نتائجك. راجع أيضًا # 863 المشتق من نفس الفرع. لذلك يجب أن نبقى مع ما ذكرته من قبل. لكن هذا يفسر السلوك المرصود.