บอร์ดที่อ่านเซนเซอร์ได้ตอนต่อกับเครื่องพัฒนา อาจเริ่มมีอาการรีสตาร์ตเมื่อเพิ่มการส่งข้อมูลหรืออุปกรณ์อีกชิ้นเข้าไป พอเห็นว่าเกิดใกล้ช่วงเริ่ม Wi-Fi ก็อาจสงสัยทั้งโค้ดเครือข่าย หน่วยความจำและไฟเลี้ยงพร้อมกัน จนไม่รู้ว่าจะเริ่มแก้ที่จุดไหน
เวลาเกิดอาการนี้ สิ่งที่ช่วยได้ก่อนคือแยกสิ่งที่รู้จริงออกจากช่วงเวลาที่ดูสัมพันธ์กัน การเกิดตอนเริ่มส่งข้อมูลยังไม่ยืนยันว่าฟังก์ชันส่งข้อมูลทำให้โปรแกรมพัง และการเปลี่ยนแหล่งจ่ายแล้วอาการเงียบลงหนึ่งครั้งก็ยังไม่ระบุว่าชิ้นส่วนเดิมตัวใดเสีย
จึงควรเก็บเหตุรีเซ็ตกับลำดับก่อนเกิดเหตุไว้ก่อนครับ แล้วค่อยไล่เส้นทางไฟและเงื่อนไขโปรแกรมตามหลักฐาน ไม่เปลี่ยนหลายอย่างพร้อมกันจนตามสาเหตุไม่ได้
ESP-IDF มี esp_reset_reason สำหรับอ่านเหตุของการรีเซ็ตตามที่ระบบรายงาน ซึ่งช่วยแยกกรณีอย่างการรีสตาร์ตด้วยซอฟต์แวร์ watchdog หรือ brownout ตามรุ่นและเงื่อนไขที่รองรับ ค่านี้เป็นจุดเริ่มต้นของการตรวจ ไม่ใช่รายงานระบุชิ้นส่วนเสียโดยตรง
ถ้ามี panic หรือ stack trace ก่อนรีเซ็ต ควรเก็บไว้พร้อมรุ่น firmware และขั้นที่กำลังทำ เพราะอาจเป็นเส้นทางปัญหาที่ต่างจากไฟเลี้ยง ส่วนข้อความจากรอบบูตใหม่ก็ต้องแยกจากข้อความก่อนเกิดเหตุ ไม่เอาบรรทัดสุดท้ายที่มองเห็นมาสรุปว่าเป็นคำสั่งที่ผิดเสมอไป
กรณี brownout เอกสาร ESP32 อธิบายว่าตัวตรวจสามารถรีเซ็ตเมื่อแรงดันเลี้ยงต่ำกว่าระดับที่ปลอดภัย และหากแรงดันลดเร็ว ข้อความแจ้งอาจพิมพ์มาไม่ครบ จึงไม่ควรใช้การไม่มีประโยคแจ้งครบทั้งบรรทัดเป็นหลักฐานเดียวว่าตัดปัญหาไฟเลี้ยงออกได้แล้ว
เส้นทางไฟอาจผ่านแหล่งจ่าย สาย ขั้วต่อ วงจรป้องกัน regulator และลายวงจรก่อนถึงโมดูล สิ่งที่บอร์ดได้รับจึงขึ้นกับทั้งเส้นทาง ไม่ใช่เพียงค่าแรงดันหรือความสามารถจ่ายกระแสที่เขียนไว้บนอะแดปเตอร์
เมื่อโหลดเปลี่ยนตามการทำงาน แรงดันที่จุดใช้งานอาจมีพฤติกรรมต่างจากตอนวัดขณะว่าง เอกสารออกแบบฮาร์ดแวร์ของ Espressif จึงให้คำแนะนำทั้งแหล่งจ่ายและตัวเก็บประจุใกล้จุดที่เกี่ยวข้อง ต้องตรวจให้ตรงชิป โมดูลและบอร์ด ไม่หยิบค่าจากขาหนึ่งไปใช้เป็นพิกัดของอีกขา
โดยเฉพาะบอร์ดพัฒนาที่มีขา USB, VIN และ3V3 การมีขาสำหรับรับไฟผ่าน regulator ไม่ได้หมายความว่าป้อนไฟระดับเดียวกันเข้าขา3V3หรือ GPIO ได้ การวางจุดจ่ายและจุดวัดจึงต้องอิง schematic ของบอร์ดที่ใช้อยู่ก่อนต่อจริง
ถ้ามีเซนเซอร์ จอหรืออุปกรณ์ขับโหลดอยู่บนแหล่งจ่ายเดียวกัน ควรทำรายการว่าแต่ละส่วนรับไฟจากจุดใดและเริ่มทำงานช่วงไหน ไม่ดูเฉพาะการใช้ของ ESP32 แล้วลืมว่าอุปกรณ์อื่นอาจดึงโหลดพร้อมกันในจังหวะเดียว
การแยกทดสอบแบบควบคุมได้ช่วยบอกว่าอาการสัมพันธ์กับการรวมโหลดใด เช่น รักษา firmware เดิมแล้วลดเฉพาะอุปกรณ์ที่เพิ่มล่าสุด หรือเปลี่ยนสายเพียงชิ้นเดียวพร้อมเก็บเงื่อนไขเดิม แต่ต้องทำภายในพิกัดและวิธีต่อที่บอร์ดรองรับ ไม่เพิ่มแรงดันเพื่อชดเชยโดยยังไม่รู้ขอบเขตวงจร
ส่วนการเพิ่ม capacitor ก็ต้องมีเหตุผลเรื่องตำแหน่ง ชนิดและวงจรที่เกี่ยวข้อง มันอาจเป็นส่วนหนึ่งของการออกแบบ แต่ไม่ได้ทำให้แหล่งจ่ายที่ไม่เพียงพอ สายที่มีปัญหา หรือ regulator ที่ใช้งานผิดเงื่อนไขกลายเป็นถูกต้องทั้งหมดด้วยชิ้นส่วนเดียว
การวัดด้วยมิเตอร์ช่วยตรวจระดับทั่วไปและความผิดปกติที่อยู่นานพอให้เห็น แต่ค่าที่อ่านบนหน้าจออาจไม่แสดงการเปลี่ยนสั้นๆ ตามโหลด หากต้องตามการยุบของแรงดันในจังหวะเฉพาะ ก็ต้องเลือกวิธีวัดที่มีความละเอียดด้านเวลาพอสำหรับคำถามนั้น
ควรวัดใกล้จุดที่อุปกรณ์ได้รับไฟ พร้อมรู้จุดอ้างอิงกราวด์และการต่อเครื่องมือที่เหมาะสม แล้วเก็บว่าโพรบอยู่ตรงไหน ภาระขณะนั้นคืออะไร และเหตุรีเซ็ตเกิดสัมพันธ์กับสัญญาณอย่างไร ไม่ดูรูปคลื่นที่ไม่มีบริบทแล้วใช้ยืนยันแรงดันทั้งบอร์ด
หากยังไม่มีเครื่องมือหรือการวัดในจุดดังกล่าว ควรบอกตรงๆ ว่าเป็นสมมติฐานจากอาการที่ต้องตรวจต่อ ไม่วาดกราฟแรงดันตกขึ้นมาให้ดูเหมือนจับมาได้แล้ว ภาพในบทนี้จึงเป็นเส้นทางการตรวจ ไม่ใช่รูปคลื่นไฟเลี้ยงหรือผลวัดจากบอร์ดผู้ใช้
เมื่อพบข้อความ brownout การปิดตัวตรวจเพื่อให้ข้อความหายไม่ได้ยืนยันว่าเงื่อนไขไฟกลับมาถูกต้อง หากต้นเหตุยังอยู่ การทำงานอาจออกนอกสภาพที่อุปกรณ์ควรได้รับอยู่เหมือนเดิม จึงควรใช้เหตุที่รายงานเป็นทางไปตรวจแหล่งจ่ายและโหลดตามขอบเขต
ระดับและพฤติกรรมของตัวตรวจต้องอ่านตามชิปกับ SDK จริง ไม่ปรับตามค่าจากคนละรุ่นโดยหวังให้บอร์ดทนกว่าเดิม และหากผลบอกว่าเป็น watchdog หรือปัญหาโปรแกรม ก็ต้องตามเส้นทางนั้นต่อ ไม่บังคับทุกการรีเซ็ตให้จบที่แหล่งจ่าย
การบันทึกข้อมูลก่อนเกิดเหตุควรคิดถึงช่วงที่ระบบยังส่งออกได้ด้วย ถ้าบอร์ดรีเซ็ตก่อนเครือข่ายพร้อม log ที่ส่งขึ้น server อย่างเดียวอาจไม่เหลือหลักฐานรอบนั้น การเก็บ console หรือข้อมูลเริ่มบูตที่เหมาะกับชุดทดลองช่วยเติมภาพได้โดยไม่แต่งเหตุการณ์แทนสิ่งที่ขาด
หลังแก้จุดที่มีหลักฐานรองรับ ควรกลับไปตรวจทั้งช่วงเริ่มระบบ การเชื่อมต่อ การส่งข้อมูล และจังหวะที่อุปกรณ์ร่วมทำงานตามแบบที่ต้องรองรับ พร้อมบันทึกแหล่งจ่าย สาย firmware และผลรีเซ็ตของแต่ละชุด จะได้เปรียบเทียบการแก้กับเงื่อนไขเดิมได้
การผ่านรอบสั้นเพียงครั้งเดียวช่วยยืนยันได้เฉพาะการตรวจครั้งนั้น ยังไม่พออ้างว่าปัญหาที่เกิดห่างๆ หายหมดแล้ว บทนี้ไม่มีผลวัดแรงดัน กระแสหรือการทดสอบระยะยาว จึงไม่ได้ชี้ว่าอะแดปเตอร์ สายหรือบอร์ดชิ้นใดของผู้ใช้เป็นต้นเหตุแล้ว
การไล่บอร์ดรีสตาร์ตควรเริ่มจากเหตุรีเซ็ตและหลักฐานก่อนเกิดเหตุ แล้วแยกเส้นทางไฟ โหลดร่วมและโปรแกรมตามข้อมูลที่พบ เมื่อเปลี่ยนทีละเงื่อนไขและวัดในจุดกับช่วงเวลาที่เกี่ยวข้อง เราจะตัดสินการแก้ได้มีหลักขึ้น โดยไม่ใช้การซ่อนข้อความเตือนหรือการเปลี่ยนหลายชิ้นพร้อมกันแทนการยืนยันสาเหตุ