Программатор возвращает WRITE FAIL на SFP+, который чисто читается: мёртвый EEPROM или что-то блокирует запись?
Мы перекодируем небольшую партию модулей под хосты заказчиков почти каждый месяц, ничего экзотичного: читаем исходную страницу, записываем строку вендора, которую хочет хост, ставим модуль в коммутатор и идём дальше. Один модуль из текущей партии отказывается от каждой записи, при этом читается идеально, и прежде чем его выбросить, хочу узнать, есть ли что ещё попробовать.
Стенд:
- USB-программатор класса CH341 с платой-переходником для SFP
- модуль SFP+, с поддержкой диагностики, читается нормально холодным и после power cycle
- та же оснастка записала три других модуля из того же лотка часом ранее
Что выводит инструмент в момент нажатия записи:
WRITE FAILПовторное чтение сразу после этого возвращает исходную страницу побайтово, то есть не записалось вообще ничего, даже частично.
Что я пробовал:
- переустановил модуль и заменил плату-переходник на запасную
- записал один байт в область, которая мне не важна, вместо всей страницы - тот же результат
- подтвердил, что чтение стабильно при нескольких циклах включения, так что проводка не на грани
Это модуль, который чисто читается, но никогда не принимает запись, просто изношен, или в самом модуле есть что-то, что может намеренно отказывать в записи?
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
Чисто читается, запись отклоняется, исходная страница после этого не тронута. Изношенный EEPROM обычно так себя не ведёт. Мёртвые ячейки дают плохое обратное чтение или страницу, записавшуюся наполовину, а не аккуратный отказ со всем нетронутым.
И поскольку даже тот единственный байт вне области вендора отскочил, это не плохая область на чипе, это компонент, отказывающий от записи целиком. Прежде чем что-либо решать, стоит выяснить две вещи. Во-первых, кто на самом деле произвёл модуль: смотрите на строку вендора в уже снятой странице, а не на то, что написано на лотке. Во-вторых, проходит ли запись, если выполнить её сразу же после подачи питания, до того как что-то ещё на шине успело поговорить с модулем. Вероятное объяснение отличается в зависимости от этих ответов, и одно из них вообще не неисправность.
Это больше похоже на защиту паролем, чем на повреждение. SFF-8472 позволяет модулю с поддержкой диагностики требовать 4-байтовый пароль перед тем, как принять любую запись. Не отправьте ничего или отправьте неправильный, и модуль отвечает на запись ошибкой, при этом чтение остаётся полностью открытым, что и есть ваш WRITE FAIL с неизменной страницей на возврате. Это особенность компонента, а не симптом умирающего.
Что это значит для вашего стенда: программатор, который знает про это, позволяет ввести пароль производителя или хоста, а те, что получше, подберут неизвестный перебором и пересчитают контрольные суммы за вас после записи. У оснастки класса CH341 вообще нет автоматизации контрольных сумм, так что даже после прохождения пароля их придётся исправлять самому, иначе получите модуль, чья страница выглядит правильной для вас, а хост всё равно отказывается его принимать.
Обычная оговорка: я сталкивался с этим на нескольких модулях, и путь с паролем там сработал, так что попробуйте на своём компоненте, прежде чем списывать что-либо со счетов.
Добавлю к этому: у некоторых вендоров пароли на самом деле не секрет. В обороте есть общие подборки паролей трансиверов Ubiquiti с записями вроде 0x00001011 и простых строк вроде SFPX и QSFP, так что если модуль вышел из этой экосистемы, попробовать известные обойдётся в пять минут, прежде чем лезть в перебор.
А если хотите инструмент, который уже знает весь процесс, а не бороться с общим программатором, UACC-SFP-WIZARD - дешёвый вариант, к которому обычно тянутся. Это не лабораторный прибор, но со стороной модуля он справляется правильно.
По теме, из опыта перекодирования модулей под хосты Huawei S5731 и S6730 и старый HP 6120XG. Когда слабым звеном оказывается кейдж или переходник, а не сам модуль, люди паяются напрямую к выводам 4 и 7 модуля, которые являются линиями I2C SDA и SCL, и работают с EEPROM, полностью убрав кейдж из уравнения. Уродливо, и делать это стоит только на компонентах, которые готов потерять, но это устраняет целый класс проблем с контактом.
Компоненты, прошедшие через это здесь: Finisar FTLX8571D3BCV и FTLX8574D3BCV, модули Intel SFP+ LR и SR, SNR-SFP+W73-3 и SNR-SFP+W37-3, а также HP J9150A.
В вашем случае чтение уже устойчиво железно при циклах питания, так что контакт - не ваша проблема. Разбирайтесь сначала с версией про пароль.
Пароль - вероятный ответ, но не останавливайтесь на "ввёл пароль и готово", потому что сразу после этого людей кусают две вещи.
Во-первых, на некоторых компонентах ввод требуется заново после того, как модуль был обесточен, так что скрипт, записывающий несколько страниц подряд, должен быть готов ввести пароль повторно, а не полагаться на то, что одна разблокировка покрывает всю сессию.
Во-вторых, контрольные суммы. С программатором класса CH341 их пересчитывают вручную. Оставьте их устаревшими, и модуль всё равно будет читаться нормально, инструмент отчитается об успехе, а хост тихо откажется принимать модуль всё равно, и тогда все снова начнут винить железо. Считайте страницу обратно и проверьте суммы, прежде чем этот модуль попадёт в коммутатор заказчика.