Lỗi đọc và ghi EEPROM trên bộ lập trình
Trước khi một module có thể được chẩn đoán hay mã hóa, nó phải được đọc — và sau đó, thường là, được ghi. Cả hai bước đều có những kiểu lỗi đặc trưng riêng. Trang này ánh xạ từng lỗi tới nguyên nhân của nó và tới cài đặt hay quy trình khắc phục, từ việc module hoàn toàn không được nhận diện cho tới một lần ghi “thành công” rồi âm thầm biến mất.
Không nhận diện được module
| Kiểm tra | Vì sao |
|---|---|
| Độ khít và khay cắm | module phải cắm hết cỡ vào đầu nối; dùng đúng adapter cho form factor của nó — một SFP trong khay cắm QSFP sẽ không được nhận diện |
| Thời gian khởi động nguồn | module cần tới ~2 giây (SFP) hoặc lâu hơn (CMIS) sau khi cắm vào trước khi bus hai dây phản hồi |
| Tín hiệu báo có module | MOD_ABS / ModPrsL phải được kích hoạt; một chân bị cong hoặc một module không có tín hiệu này sẽ trông như không hề có module |
| Trạng thái công suất thấp (CMIS) | thông tin nhận dạng đọc được ngay ở LowPwr, nhưng một số host/bộ lập trình lại cần trạng thái Ready để truy cập đầy đủ |
| Tốc độ bus | bắt đầu ở 100 kHz hoặc thấp hơn; một số module trả về NACK ở 400 kHz |
| Module chết | không có DDM, không có thông tin nhận dạng ở bất kỳ tốc độ nào — hãy xác nhận trên một board thứ hai trước khi kết luận module hỏng |
Đọc ra FFh, 00h hoặc dữ liệu rác
| Triệu chứng | Nguyên nhân | Cách khắc phục |
|---|---|---|
| Toàn bộ FFh | I²C NACK — không có thiết bị ở địa chỉ đó, hoặc trang không tồn tại | kiểm tra địa chỉ (A0h thông tin nhận dạng so với A2h chẩn đoán trên SFP; chỉ một A0h với phân trang trên QSFP/CMIS) |
| Toàn bộ 00h | module không có nguồn / đang bị giữ reset; hoặc EEPROM thực sự còn trống | kiểm tra nguồn cấp cho khay cắm, sự hiện diện của module; module trống vẫn tồn tại (hàng chưa mã hóa) |
| Đúng độ dài, sai nội dung | đang đọc nhầm trang so với dự định | ghi byte chọn trang (127) rồi đọc lại; trên CMIS còn cần cả chọn bank (126) |
| Byte bị lỗi / lệch | bus quá nhanh, dây quá dài, xung đột với host | hạ xuống ≤ 100 kHz; dùng dây dẫn ngắn; đọc trên bàn thử, không đọc khi module đang cắm trong switch đang chạy |
| Đọc A2h thất bại, A0h vẫn tốt | module không có chẩn đoán, hoặc khối chẩn đoán bị bảo vệ | kiểm tra A0h byte 92 bit 6 (có hỗ trợ DDM không); một số loại được bảo vệ ghi chỉ trả lời ở A0h |
| Giá trị thay đổi giữa các lần đọc | giám sát thời gian thực — bình thường; hoặc dữ liệu chưa sẵn sàng | byte DDM vốn dĩ phải thay đổi; kiểm tra bit báo dữ liệu sẵn sàng trước khi tin vào một lần chụp nhanh |
Ghi thất bại hoàn toàn
WRITE FAIL, NACK trên dữ liệu, hoặc byte đọc lại vẫn không đổi:
| Nguyên nhân | Cách nhận biết | Cần làm gì |
|---|---|---|
| Cần mật khẩu (bộ điều khiển firmware) | việc ghi bị từ chối cho tới khi giá trị đúng được đặt vào địa chỉ mật khẩu (SFP A2h 0x7B–0x7E, QSFP 123–126, CMIS 122–125) | nhập mật khẩu của module trong Bộ nhớ được bảo vệ ghi và mật khẩu; mật khẩu của các nhà sản xuất đã biết được áp dụng tự động từ cơ sở dữ liệu |
| Bảo vệ ghi phần cứng | chỉ đọc bất kể mật khẩu, vẫn giữ nguyên qua các lần tắt bật nguồn | chân WP phải do board của bộ lập trình điều khiển — riêng phần mềm không thể làm được; xem Các kiểu bảo vệ ghi |
| Định thời | lỗi chập chờn, trang chỉ được ghi một phần | giảm tốc độ xung nhịp (thường cần ~1 kHz để ghi EEPROM ổn định), tôn trọng thời gian chu kỳ ghi (5–10 ms) giữa các byte/trang, thêm độ trễ giữa các khối |
| Vùng chỉ đọc | một số byte cụ thể không bao giờ thay đổi (checksum, ngưỡng trên một số dòng, vùng nhà sản xuất) | EEPROM có một vùng được bảo vệ theo thiết kế; chỉ ghi những trường mà module cho phép |
| Sai trạng thái | module CMIS có thể yêu cầu LowPwr, hoặc một data path đã bị vô hiệu hóa, trước khi chấp nhận ghi | đưa module về đúng trạng thái yêu cầu trước |
| Chưa chọn trang | đã ghi đúng offset nhưng sai trang | đặt byte 127 (và 126) trước khi ghi, rồi xác minh bằng cách đọc lại byte chọn trang |
Ghi “thành công” nhưng không giữ được
- Quay lại giá trị cũ sau khi tắt bật nguồn — module lưu các thay đổi vào bộ nhớ tạm và cần lệnh save riêng của nhà sản xuất; thiếu lệnh đó, bản dữ liệu cũ sẽ quay trở lại. Được xử lý bằng một script lập trình (kiểu bảo vệ ghi 4).
- Quay lại ngay lập tức — vi điều khiển đồng bộ ngược EEPROM từ bộ nhớ riêng của nó và ghi đè lên các byte bạn vừa ghi; cần thuật toán riêng của nhà sản xuất (kiểu 5).
- Một số byte giữ được, số khác thì không — bản đồ bộ nhớ chỉ được bảo vệ một phần; hãy ghi từng trường một và xác minh từng trường.
Host từ chối module sau khi ghi thành công
| Nguyên nhân | Cách khắc phục |
|---|---|
| Checksum đã cũ — CC_BASE (byte 63), CC_EXT (95), CC_DMI (A2h 95), QSFP 191/223 | tính lại; CodingBox tự làm việc này mỗi khi ghi (bản đồ bộ nhớ) |
| Thông tin nhận dạng giờ không nhất quán — ví dụ đã đổi nhà sản xuất nhưng mã tuân thủ hoặc bước sóng lại ngụ ý phần cứng khác | giữ thông tin nhận dạng nhất quán với phần quang thực tế (Tốc độ & tốc độ truyền, Sai lệch vật lý) |
| Đã ghi theo bố cục của sai loại module | một XFP bị ghi như thể là SFP, hoặc nhầm trang trên QSFP — khôi phục từ bản sao lưu |
Module chết sau khi ghi
Ghi dữ liệu rác đè lên các hằng số hiệu chuẩn, ngưỡng hoặc vùng riêng của nhà sản xuất (nơi một số bộ điều khiển lưu cấu hình của chúng) có thể khiến module “biến thành cục gạch” không thể cứu được. Cách khôi phục: phục hồi bản sao lưu mà CodingBox đã tạo trước lần ghi đó từ Code database, rồi chỉ ghi lại những trường thực sự cần thiết.
Quy tắc vàng
- Đọc và lưu trước — mỗi lần ghi đều nên được thực hiện sau một lần đọc đầy đủ, lưu vào cơ sở dữ liệu.
- Xác định kiểu bảo vệ trước lần ghi đầu tiên (Các kiểu bảo vệ ghi).
- Đi chậm lại — tốc độ xung nhịp và định thời giữa các byte giải quyết được phần lớn các lỗi “ngẫu nhiên”.
- Chỉ ghi những gì thật sự cần — từng trường, không phải cả trang, trừ khi đang khôi phục một bản ảnh đầy đủ.
- Xác minh bằng cách đọc lại sau khi tắt bật nguồn.
Trong CodingBox
CodingBox đọc module với đúng địa chỉ và cách phân trang theo từng form factor, hiển thị byte thô và byte đã giải mã trong EEPROM editor, tự tính lại checksum mỗi khi ghi, tự động lưu bản sao lưu, và hỗ trợ nhập mật khẩu cùng script lập trình cho các module có bảo vệ hoặc cần lệnh save (Ghi module). Nếu nghi ngờ lỗi ở cấp độ board, xem mục Xử lý sự cố của sản phẩm.
Cơ chế hoạt động của bus đứng sau các lỗi này — địa chỉ, chọn trang, thời gian chu kỳ ghi, clock stretching: Giao diện hai dây.
Vì sao một module phản hồi theo đúng cách nó phản hồi — bộ nhớ được mô phỏng bởi MCU, cửa sổ khởi động, clock stretching, các vùng được bảo vệ: Bộ điều khiển & firmware.