อุปกรณ์ที่รีบูตแล้วกลับมาออนไลน์ได้ช่วยให้ระบบทำงานต่อ แต่ไม่ได้อธิบายว่าก่อนหน้านั้นโปรแกรมหยุดเพราะอะไร หากเก็บเพียงข้อความตอนเชื่อมต่อใหม่ เราอาจเห็นผลของการเริ่มรอบถัดไปโดยไม่มีหลักฐานช่วงที่ล้มเหลืออยู่
ESP-IDF มีทั้งข้อความจาก panic handler และกลไก core dump สำหรับเก็บสภาพบางส่วนของโปรแกรมเมื่อเกิด fatal error แต่ต้องเตรียมทางเก็บและไฟล์ที่ใช้วิเคราะห์ให้สัมพันธ์กับ firmware ที่อยู่บนบอร์ด
จุดเริ่มจึงควรเป็นการออกแบบชุดหลักฐานก่อนเกิดเหตุครับ แล้วอ่านให้รู้ว่าสิ่งที่เก็บได้บอกอะไรและยังไม่บอกอะไร แทนการรอให้ล้มแล้วค่อยหวังว่าทุกค่าในหน่วยความจำจะกลับมาอ่านได้
Reset reason กับ panic message ช่วยแยกกลุ่มเหตุการณ์ได้ แต่การกลับมาเริ่มใหม่ไม่ได้หมายความว่าทุกรอบผ่าน panic handler แบบเดียวกัน การปิดไฟหรือเหตุที่ไม่เหลือเวลาทำขั้นเก็บข้อมูลจึงไม่ควรถูกคาดว่าจะมี core dump สมบูรณ์เหมือนการจำลอง software exception
เริ่มจากเก็บ boot log ที่เกี่ยวข้องกับเหตุ พร้อมตัวตนบอร์ด firmware และเวลาที่พอผูกกับระบบภายนอกได้ หากเวลาบนบอร์ดยังไม่พร้อม ต้องแยกสถานะนั้น ไม่เติมเวลาปฏิทินที่ดูครบแต่ไม่ใช่หลักฐานจริง
การจำแนกนี้ช่วยเลือกทางไล่ต่อ เช่น ข้อความที่ชี้เรื่องการเข้าถึงหน่วยความจำควรตามโค้ดกับข้อมูลที่เกี่ยวข้อง ส่วนอาการที่สัมพันธ์กับไฟเลี้ยงก็ต้องมีหลักฐานทางฮาร์ดแวร์เพิ่มเติม ไม่เปลี่ยนทุกการรีบูตให้เป็น bug ในฟังก์ชันสุดท้ายที่พิมพ์ log
Core dump ของ ESP-IDF เก็บข้อมูลสถานะสำหรับวิเคราะห์หลังเหตุ เช่น register กับข้อมูล task และ stack ตามความสามารถและ configuration ที่เลือก ไม่ใช่ภาพทุก byte ของระบบพร้อมประวัติตลอดช่วงก่อนล้มโดยอัตโนมัติ
จำนวน task รูปแบบไฟล์และพื้นที่หน่วยความจำที่รวมมีเงื่อนไขของมัน บางการตั้งค่าเพิ่มข้อมูลที่เก็บได้แต่ทำให้ไฟล์ใหญ่ขึ้น ส่วนหน่วยความจำภายนอกก็มีข้อจำกัดที่ต้องอ่านตามรุ่น การเปิด GDB แล้วเห็นชื่อ variable จึงยังไม่รับรองว่าค่าที่อยากอ่านอยู่ใน dump จริง
ความต่างนี้มีผลต่อข้อสรุปโดยตรง หากไม่มี buffer ที่เคยรับข้อมูลเครือข่ายอยู่ในหลักฐาน เราไม่ควรสรุปเนื้อหาเดิมของมันจาก pointer ที่เห็นเพียงตัวเดียว ควรระบุว่าส่วนใดตรวจได้และส่วนใดต้องเพิ่มการเก็บในรอบทดสอบถัดไป
Checksum ของไฟล์ช่วยตรวจความสมบูรณ์ตามกลไกที่เลือก แต่ไม่ได้บอกว่า root cause ถูกวินิจฉัยแล้ว หรือว่าทุกบริเวณที่สนใจถูกบันทึกครบ การตรวจไฟล์กับการตีความเหตุยังเป็นคนละขั้น
ESP-IDF รองรับการเก็บ core dump ลง flash หรือส่งออก UART ตามการตั้งค่า หากใช้ flash ต้องมี partition และขนาดที่เหมาะกับข้อมูลที่จะเก็บ ไม่เพิ่ม partition ตามตัวอย่างโดยไม่ดู layout ของ firmware และข้อมูลเดิม
ทาง flash ช่วยให้มีโอกาสอ่านหลักฐานหลังเริ่มใหม่ แต่ต้องมีนโยบายว่าอ่านออกเมื่อไร เก็บเวอร์ชันอย่างไรและจะจัดการหลักฐานเดิมก่อนถูกใช้พื้นที่ต่ออย่างไร ไม่ถือว่ามีไฟล์อยู่บนอุปกรณ์แล้วจะไม่ถูกเปลี่ยนไปอีกตลอดอายุการใช้งาน
ทาง UART ต้องมีผู้รับที่เก็บข้อความครบตามรูปแบบ หากไม่มีคอมพิวเตอร์หรือระบบรับต่ออยู่ตอนเกิดเหตุ ข้อความที่ส่งออกก็ไม่ได้กลายเป็นไฟล์ย้อนหลังให้เอง ควรทดสอบว่าการเก็บไม่ตัดกลางและรู้ส่วนที่เป็นข้อมูล dump จริงตามคำสั่งของเครื่องมือ
ถ้าใช้ flash encryption หรือมาตรการป้องกันข้อมูลอื่น ต้องเลือกวิธีอ่านตามที่ระบบรองรับ ไม่ปิดการป้องกันของอุปกรณ์จริงเพื่อให้เครื่องมืออ่านง่าย และไม่คัดตัวเลขขนาด partition จากตัวอย่างไปใช้ราวกับเป็นขนาดที่พอกับทุก build
Address ใน backtrace ต้องอาศัยข้อมูลของ build เพื่อแปลงเป็นฟังก์ชัน ไฟล์และบรรทัด IDF Monitor ใช้ไฟล์ ELF ของโปรแกรมในขั้น decode การใช้ ELF ที่เพิ่ง build ใหม่หลังแก้โค้ดจึงอาจทำให้การจับตำแหน่งไม่ตรงกับ firmware ที่สร้างเหตุ
ควรเก็บ ELF map configuration และข้อมูลรุ่นเครื่องมือหรือ source revision ร่วมกับ artifact ของ firmware ตามที่โครงการต้องใช้ พร้อมมีตัวเชื่อมจากอุปกรณ์กลับไป build นั้น ไม่เก็บเพียงไฟล์ binary ที่ตั้งชื่อว่า latest แล้วทับทุกครั้ง
การ build จาก commit เดิมอย่างเดียวอาจยังมีรายละเอียดสภาพแวดล้อมที่เปลี่ยนไป จึงควรรักษา artifact ที่ใช้ส่งจริงไว้เมื่อจำเป็นต่อการวิเคราะห์ ไม่คาดว่าจะสร้างไฟล์เทียบตำแหน่งเดิมได้ทุกกรณีจากความทรงจำของคนทำ
ถ้ามี OTA หลายรุ่นอยู่ในอุปกรณ์กลุ่มเดียวกัน ตัวตน build ยิ่งสำคัญ เพราะ log จากสองเครื่องที่เหมือนกันภายนอกอาจเป็นคำสั่งคนละฉบับ การรวมหลักฐานโดยไม่แยกรุ่นอาจพาไปแก้เหตุที่ไม่มีอยู่ในรุ่นนั้นแล้ว
เริ่มจาก panic reason task ที่เกี่ยวข้อง และ call stack แล้วเทียบกับโค้ดฉบับที่ตรงกัน จุดที่เข้าถึง pointer ผิดอาจเป็นจุดที่ความเสียหายแสดงอาการ แต่ข้อมูลอาจถูกทำผิดจากทางอื่นมาก่อน ต้องตามอายุและเจ้าของหน่วยความจำประกอบ
กรณีเหตุเกิดใน ISR หรือมี ROM function อยู่ใน stack ก็มีรายละเอียดการ decode ตาม target และเครื่องมือ การเจอบรรทัดที่แปลไม่ได้ไม่ใช่หลักฐานว่าทุกส่วนของ dump ใช้ไม่ได้ แต่ต้องระบุขอบเขตที่ยังอ่านไม่ได้แทนการเดาชื่อฟังก์ชันขึ้นมา
การวิเคราะห์ควรแยกข้อเท็จจริง เช่น ที่อยู่ที่เข้าถึงหรือ task ที่หยุด ออกจากสมมติฐาน เช่น buffer ถูกคืนก่อนใช้ แล้วออกแบบการทดสอบที่แยกสมมติฐานนั้นได้ ไม่สรุปว่าฟังก์ชันบนสุดเป็นผู้ทำหน่วยความจำเสียเสมอ
ใช้ firmware และอุปกรณ์ทดลองที่ไม่ควบคุมงานจริงเพื่อตรวจวงจร panic เก็บ dump อ่านกลับ และ decode กับ artifact ที่รักษาไว้ การทดสอบควรยืนยันว่าทางเก็บทำงาน ไม่จำเป็นต้องสร้างเหตุรุนแรงกับอุปกรณ์ที่ผู้ใช้กำลังพึ่งอยู่
Dump อาจมีข้อมูลจากหน่วยความจำที่ไม่ควรเผยแพร่ จึงควรให้คนที่เกี่ยวข้องเข้าถึงตามขอบเขต และตัดข้อมูลก่อนทำรายงานสาธารณะ ข้อความที่ใช้ส่งต่ออาจสรุป task รุ่นและตำแหน่งที่ตรวจแล้ว โดยไม่แนบหน่วยความจำทั้งก้อนทุกครั้ง
การตาม crash หลัง ESP32 เริ่มใหม่ต้องเตรียมทั้งทางเก็บสถานะและตัวตน build ที่ตรงกัน เมื่ออ่าน core dump ตามขอบเขตหน่วยความจำที่มีจริง พร้อมแยกตำแหน่งที่พบเหตุออกจากสมมติฐานต้นเหตุ เราจะได้หลักฐานที่ใช้ตรวจต่อได้และลดการแก้แบบเดา แม้อุปกรณ์จะกลับมาออนไลน์จนมองไม่เห็นช่วงที่ล้มแล้วก็ตาม