El programador devuelve WRITE FAIL en un SFP+ que se lee limpio: ¿EEPROM muerta o algo bloqueando las escrituras?
Recodificamos un pequeño lote de módulos para hosts de clientes casi todos los meses, nada exótico: leer la página original, escribir la cadena de vendedor que el host quiere, poner el módulo en el switch y seguir adelante. Un módulo del lote actual rechaza cada escritura mientras se lee perfectamente, y antes de desecharlo quisiera saber si queda algo que probar.
Banco:
- programador USB clase CH341 con una placa breakout para SFP
- módulo SFP+, con capacidad de diagnóstico, se lee bien en frío y después de un ciclo de energía
- el mismo montaje escribió otros tres módulos de la misma bandeja una hora antes
Lo que imprime la herramienta en el momento en que doy escribir:
WRITE FAILVolver a leer justo después me devuelve la página original byte por byte, así que no se quedó nada, ni siquiera parcialmente.
Lo que probé:
- reasenté el módulo y cambié la placa breakout por una de repuesto
- escribí un solo byte en una región que no me importa en vez de la página completa, mismo resultado
- confirmé que la lectura es estable a través de varios ciclos de energía, así que el cableado no está marginal
¿Un módulo que lee limpio pero nunca acepta una escritura simplemente está gastado, o hay algo en el propio módulo que puede rechazar escrituras a propósito?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Lee limpio, rechaza las escrituras, la página original intacta después. Así no se comporta normalmente una EEPROM gastada. Las celdas muertas te dan una lectura de vuelta mala o una página que quedó a medio escribir, no un rechazo prolijo con todo intacto.
Y ya que hasta ese único byte fuera del área de vendedor rebotó, esto no es una región mala del chip, es la pieza rechazando escrituras en bloque. Dos cosas vale la pena fijar antes de decidir nada. Primero, quién realmente fabricó el módulo: guíate por la cadena de vendedor en la página que ya volcaste, no por lo que decía la etiqueta de la bandeja. Segundo, si una escritura se queda en el momento en que llega la energía, antes de que nada más en el bus le haya hablado al módulo. La explicación probable difiere según esas respuestas, y una de ellas no es una falla en absoluto.
Eso se lee más como protección por contraseña que como daño. SFF-8472 permite que un módulo con capacidad de diagnóstico exija una contraseña de 4 bytes antes de aceptar cualquier escritura. No envíes nada, o envía la equivocada, y el módulo responde a la escritura con un error mientras las lecturas se quedan completamente abiertas, que es exactamente tu WRITE FAIL con la página volviendo sin cambios. Es una característica de la pieza, no un síntoma de una que se está muriendo.
Lo que eso significa para tu banco: un programador que sepa de esto te deja ingresar una contraseña de fabricante o de host, y los mejores van a intentar por fuerza bruta una desconocida y recalcular los checksums por ti después de la escritura. Un montaje clase CH341 no tiene ninguna automatización de checksums, así que incluso después de pasar la contraseña tienes que arreglar los checksums tú mismo, de lo contrario terminas con un módulo cuya página te parece correcta a ti y que el host de todos modos sigue rechazando.
Advertencia habitual: me ha pasado esto en un puñado de módulos y ahí la vía de la contraseña funcionó, así que pruébala en tu propia pieza antes de descartar nada.
Para agregar a eso: para algunos vendedores las contraseñas no son realmente secretas. Hay colecciones compartidas circulando de contraseñas de transceptores Ubiquiti con entradas como 0x00001011 y cadenas simples como SFPX y QSFP, así que si el módulo salió de ese ecosistema te cuesta cinco minutos probar las conocidas antes de acercarte siquiera a la fuerza bruta.
Y si quieres una herramienta que ya conozca todo el flujo en vez de pelear con un programador genérico, el UACC-SFP-WIZARD es la opción barata a la que la gente recurre. No es un instrumento de laboratorio, pero maneja bien el lado del módulo.
Relacionado, de recodificar módulos para hosts Huawei S5731 y S6730 y un viejo HP 6120XG. Cuando la jaula o el breakout es el eslabón débil en vez del módulo, la gente suelda directamente a los pines 4 y 7 del módulo, que son las líneas I2C SDA y SCL, y maneja la EEPROM con la jaula completamente fuera de la ecuación. Feo, y solo lo haces en piezas que estás dispuesto a perder, pero elimina toda una clase de problemas de contacto.
Piezas que han pasado por eso aquí: Finisar FTLX8571D3BCV y FTLX8574D3BCV, módulos Intel SFP+ LR y SR, SNR-SFP+W73-3 y SNR-SFP+W37-3, más un HP J9150A.
En tu caso la lectura ya es sólida como roca a través de los ciclos de energía, así que el contacto no es tu problema. Persigue primero el ángulo de la contraseña.
La contraseña es la respuesta probable, pero no te quedes en "escribe la contraseña y ya está", porque dos cosas muerden a la gente justo después de eso.
Primero, en algunas piezas hay que ingresarla de nuevo después de que el módulo se apagó, así que un script que escribe varias páginas seguidas tiene que estar preparado para volver a ingresarla en vez de asumir que un desbloqueo cubre toda la sesión.
Segundo, los checksums. Con un programador clase CH341 los recalculas a mano. Déjalos desactualizados y el módulo de todos modos se lee bien, tu herramienta reporta éxito, y el host de todos modos rechaza el módulo calladamente, momento en el cual todos vuelven a culpar al hardware. Lee la página de vuelta y verifica las sumas antes de que ese módulo entre a un switch de cliente.