ข้อผิดพลาดในการอ่านและเขียน EEPROM บนเครื่องโปรแกรม

ก่อนที่จะวินิจฉัยหรือเขียนโค้ดโมดูลได้ ต้องอ่านมันก่อน — แล้วส่วนใหญ่ก็ต้องเขียนด้วย ทั้งสองขั้นตอนล้มเหลวได้ในรูปแบบที่มีลักษณะเฉพาะ หน้านี้จับคู่ความล้มเหลวแต่ละแบบเข้ากับสาเหตุ และกับการตั้งค่าหรือขั้นตอนที่แก้ไขมันได้ ตั้งแต่โมดูลที่มองไม่เห็นเลย ไปจนถึงการเขียนที่ “สำเร็จ” แล้วก็หายไปเงียบ ๆ

ตรวจไม่พบโมดูล

ตรวจสอบ	เพราะอะไร
การเสียบและเครดเดิล	โมดูลต้องเสียบจนสุดในคอนเนกเตอร์; ใช้อะแดปเตอร์ที่ตรงกับฟอร์มแฟกเตอร์ของมัน — SFP ในเครดเดิลของ QSFP จะไม่ถูกมองเห็น
เวลาในการเปิดเครื่อง	โมดูลต้องการเวลาสูงสุดราว ~2 s (SFP) หรือนานกว่านั้น (CMIS) หลังเสียบ ก่อนที่บัสสองสายจะตอบสนอง
สัญญาณแจ้งว่ามีโมดูล	MOD_ABS / ModPrsL ต้องทำงาน; ขาโค้งงอหรือโมดูลที่ไม่มีสัญญาณนี้จะดูเหมือนไม่มีโมดูลอยู่
สถานะกำลังต่ำ (CMIS)	ข้อมูลระบุตัวตนอ่านได้ในสถานะ LowPwr แต่โฮสต์/เครื่องโปรแกรมบางตัวต้องการสถานะ Ready เพื่อเข้าถึงได้เต็มรูปแบบ
ความเร็วบัส	เริ่มที่ 100 kHz หรือต่ำกว่า; โมดูลบางตัวตอบ NACK ที่ 400 kHz
โมดูลตาย	ไม่มี DDM ไม่มีข้อมูลระบุตัวตนไม่ว่าที่ความเร็วใด — ยืนยันบนบอร์ดที่สองก่อนสรุปว่าโมดูลตาย

การอ่านได้ค่า FFh, 00h หรือค่าขยะ

อาการ	สาเหตุ	วิธีแก้
ทั้งหมดเป็น FFh	I²C NACK — ไม่มีอุปกรณ์ที่แอดเดรสนั้น หรือไม่มีเพจนั้นอยู่	ตรวจสอบแอดเดรส (A0h ข้อมูลระบุตัวตน เทียบกับ A2h การวินิจฉัยบน SFP; A0h ตัวเดียวพร้อมการสลับเพจบน QSFP/CMIS)
ทั้งหมดเป็น 00h	โมดูลไม่มีไฟเลี้ยง / ถูกค้างอยู่ในสถานะรีเซ็ต; หรือ EEPROM ว่างเปล่าจริง ๆ	ตรวจสอบไฟเลี้ยงที่เครดเดิล, การมีอยู่ของโมดูล; โมดูลเปล่ามีอยู่จริง (สต็อกที่ยังไม่ได้เขียนโค้ด)
ความยาวถูกต้อง แต่เนื้อหาผิด	กำลังอ่านคนละเพจกับที่ตั้งใจ	เขียนไบต์เลือกเพจ (127) แล้วอ่านใหม่; บน CMIS ต้องเลือกแบงก์ด้วย (126)
ไบต์เพี้ยน / เลื่อนตำแหน่ง	บัสเร็วเกินไป, สายยาวเกินไป, แย่งใช้งานกับโฮสต์	ลดลงมาที่ ≤ 100 kHz; ใช้สายสั้น; อ่านบนโต๊ะทดสอบ ไม่ใช่ในสวิตช์ที่ใช้งานจริง
อ่าน A2h ไม่ได้ แต่ A0h ปกติดี	โมดูลไม่มีการวินิจฉัย หรือบล็อกการวินิจฉัยถูกป้องกันไว้	ตรวจสอบ A0h ไบต์ 92 บิต 6 (มีการติดตั้ง DDM หรือไม่); โมดูลบางชนิดที่ป้องกันการเขียนตอบเฉพาะ A0h เท่านั้น
ค่าที่ได้เปลี่ยนไปในแต่ละครั้งที่อ่าน	มอนิเตอร์แบบเรียลไทม์ — ปกติ; หรือ ข้อมูลยังไม่พร้อม	ไบต์ของ DDM ควรเปลี่ยนแปลงอยู่แล้ว; ตรวจสอบบิตข้อมูลพร้อมก่อนเชื่อค่าที่อ่านได้ครั้งเดียว

การเขียนล้มเหลวทันที

WRITE FAIL, NACK บนข้อมูล หรืออ่านไบต์กลับมาแล้วไม่เปลี่ยนแปลง:

สาเหตุ	วิธีสังเกต	สิ่งที่ต้องทำ
ต้องใช้รหัสผ่าน (คอนโทรลเลอร์เฟิร์มแวร์)	การเขียนถูกปฏิเสธจนกว่าจะใส่ค่าที่ถูกต้องไว้ที่แอดเดรสรหัสผ่าน (SFP A2h 0x7B–0x7E, QSFP 123–126, CMIS 122–125)	กรอกรหัสผ่านของโมดูลในหน่วยความจำที่มีการป้องกันและรหัสผ่าน; รหัสผ่านของผู้ผลิตที่รู้จักแล้วจะถูกนำมาใช้จากฐานข้อมูลให้อัตโนมัติ
การป้องกันการเขียนด้วยฮาร์ดแวร์	เป็นแบบอ่านอย่างเดียวไม่ว่าจะใส่รหัสผ่านหรือไม่ และคงอยู่แม้ปิดเปิดไฟใหม่	ขา WP ต้องถูกควบคุมโดยบอร์ดโปรแกรม — ซอฟต์แวร์อย่างเดียวทำไม่ได้; ดูชนิดการป้องกันการเขียน
จังหวะเวลา	ล้มเหลวเป็นพัก ๆ, เขียนเพจได้แค่บางส่วน	ลดความเร็วสัญญาณนาฬิกาลง (มักต้องใช้ ~1 kHz เพื่อให้เขียน EEPROM ได้เสถียร), เว้นเวลารอบการเขียน (5–10 ms) ระหว่างไบต์/เพจ, เพิ่มดีเลย์ระหว่างบล็อก
พื้นที่อ่านอย่างเดียว	ไบต์บางตัวไม่เปลี่ยนแปลงเลย (เช็กซัม, ค่าเกณฑ์ในบางรุ่น, พื้นที่ของผู้ผลิต)	EEPROM มีพื้นที่ที่ถูกป้องกันไว้ตามการออกแบบ; เขียนเฉพาะฟิลด์ที่โมดูลอนุญาตเท่านั้น
สถานะผิด	โมดูล CMIS อาจต้องการสถานะ LowPwr หรือ data-path ที่ถูกปิดใช้งานก่อน จึงจะยอมให้เขียนได้	ปรับโมดูลไปที่สถานะที่ต้องการก่อน
ยังไม่ได้เลือกเพจ	คุณเขียนออฟเซตที่ถูกต้อง แต่ผิดเพจ	ตั้งค่าไบต์ 127 (และ 126) ก่อนเขียน แล้วตรวจสอบด้วยการอ่านไบต์เลือกเพจกลับมาดู

การเขียน “สำเร็จ” แต่ไม่คงอยู่

ย้อนกลับหลังปิดเปิดไฟใหม่ — โมดูลเก็บค่าที่เขียนไว้ในหน่วยความจำชั่วคราว และต้องการคำสั่งบันทึกของผู้ผลิต; ถ้าไม่มีคำสั่งนี้ อิมเมจเก่าจะกลับมา จัดการได้ด้วยสคริปต์การเขียนโค้ด (การป้องกันการเขียนชนิด 4)
ย้อนกลับทันที — ไมโครคอนโทรลเลอร์คัดลอก EEPROM มาจากที่เก็บข้อมูลของตัวเองแล้วเขียนทับไบต์ของคุณ; ต้องใช้อัลกอริทึมของผู้ผลิต (ชนิด 5)
บางไบต์คงอยู่ บางไบต์ไม่คงอยู่ — แผนผังหน่วยความจำที่ถูกป้องกันเพียงบางส่วน; เขียนทีละฟิลด์แล้วตรวจสอบทุกครั้ง

โฮสต์ปฏิเสธโมดูลหลังเขียนสำเร็จ

สาเหตุ	วิธีแก้
เช็กซัมล้าสมัย — CC_BASE (ไบต์ 63), CC_EXT (95), CC_DMI (A2h 95), QSFP 191/223	คำนวณใหม่; CodingBox ทำสิ่งนี้ให้อัตโนมัติทุกครั้งที่เขียน (แผนผังหน่วยความจำ)
ข้อมูลระบุตัวตนไม่สอดคล้องกันแล้ว — เช่น เปลี่ยนผู้ผลิตแล้ว แต่รหัสความสอดคล้องหรือความยาวคลื่นบ่งบอกถึงฮาร์ดแวร์คนละแบบ	รักษาข้อมูลระบุตัวตนให้สอดคล้องกับออปติกจริง (ความเร็วและอัตรา, ความไม่ตรงกันทางกายภาพ)
เขียนตามผังของโมดูลผิดชนิด	เขียน XFP ราวกับเป็น SFP หรือสับสนเรื่องเพจของ QSFP — กู้คืนจากข้อมูลสำรอง

โมดูลตายหลังเขียน

การเขียนค่าขยะทับค่าคงที่การสอบเทียบ, ค่าเกณฑ์ หรือพื้นที่เฉพาะของผู้ผลิต (ที่คอนโทรลเลอร์บางตัวเก็บการตั้งค่าของตัวเองไว้) อาจทำให้โมดูลใช้งานไม่ได้เลย วิธีกู้คืน: กู้คืนข้อมูลสำรองที่ CodingBox เก็บไว้ก่อนการเขียนจากCode database แล้วจึงเขียนเฉพาะฟิลด์ที่ต้องการเท่านั้น

กฎทอง

อ่านและบันทึกก่อนเสมอ — ทุกการเขียนควรเกิดขึ้นหลังจากอ่านค่าเต็มรูปแบบและบันทึกลงฐานข้อมูลแล้ว
ระบุชนิดการป้องกันก่อนพยายามเขียนครั้งแรก (ชนิดการป้องกันการเขียน)
ไปให้ช้า — ความเร็วสัญญาณนาฬิกาและจังหวะเวลาระหว่างไบต์แก้ความล้มเหลวแบบ “สุ่ม” ได้ส่วนใหญ่
เขียนเฉพาะสิ่งที่ตั้งใจ — เขียนเป็นฟิลด์ ไม่ใช่ทั้งเพจ เว้นแต่กำลังกู้คืนอิมเมจ
ตรวจสอบด้วยการอ่านซ้ำหลังปิดเปิดไฟใหม่

ใน CodingBox

CodingBox อ่านโมดูลด้วยแอดเดรสและการสลับเพจที่ถูกต้องตามฟอร์มแฟกเตอร์แต่ละแบบ แสดงไบต์ดิบและไบต์ที่ถอดรหัสแล้วในEEPROM editor คำนวณเช็กซัมใหม่เมื่อเขียน เก็บข้อมูลสำรองให้อัตโนมัติ และรองรับการกรอกรหัสผ่านกับสคริปต์การเขียนโค้ดสำหรับโมดูลที่มีการป้องกันและโมดูลที่ต้องใช้คำสั่งบันทึก (การเขียนโมดูล) หากสงสัยว่าเป็นความผิดพลาดระดับบอร์ด ให้ดูการแก้ไขปัญหาของผลิตภัณฑ์

กลไกของบัสเบื้องหลังความล้มเหลวเหล่านี้ — แอดเดรส, การเลือกเพจ, เวลารอบการเขียน, การยืดสัญญาณนาฬิกา: อินเทอร์เฟซสองสาย

เหตุผลที่โมดูลตอบสนองแบบที่เป็นอยู่ — หน่วยความจำที่จำลองโดย MCU, ช่วงเวลาบูต, การยืดสัญญาณนาฬิกา, พื้นที่ที่ถูกป้องกัน: คอนโทรลเลอร์และเฟิร์มแวร์

หากพบข้อมูลที่ไม่ถูกต้องหรือข้อผิดพลาดในบทความนี้ ให้เลือกข้อความส่วนนั้นแล้วกด Ctrl+Enter เพื่อ