Rostyk.07

Діагностика HPE Aruba 6000 48G (R8N85A) — аналіз логів консолі та підозра на несправність PHY BCM54182 Маю в ремонті комутатор Hewlett Packard Enterprise Aruba 6000 48G (R8N85A), який не може нормально завантажити операційну систему ArubaOS-CX. Пристрій періодично перезавантажується по колу. Повторне встановлення системи та базова апаратна діагностика не дали результату. 1. Поведінка пристрою Після ввімкнення комутатор спочатку запускається нормально. Приблизно через три хвилини загоряються всі світлодіоди на передній панелі, після чого пристрій перезавантажується. Далі він знову намагається завантажити систему, але через певний час повторно перезавантажується. Після кількох таких циклів комутатор іноді залишається ввімкненим, проте повністю завантажити систему не може. Спочатку перевірив блок живлення та замінив його на завідомо справний. Це не допомогло. Також перевірив кнопку Reset: вона працює коректно й дозволяє скинути налаштування до заводських, але на проблему із завантаженням не впливає. Додатково відключив живлення PoE 54 В, однак комутатор продовжив перезавантажуватися. 2. Перевірка пам'яті та перевстановлення системи На платі встановлені, зокрема, такі компоненти: CPLD: 5M1270ZF256C5N NAND: THGBMJG7C1LBAIL SPI Flash: 25Q128 Оскільки в мене є справний комутатор цієї ж моделі, я зчитав вміст SPI Flash із робочого пристрою та записав його в пам'ять несправного комутатора. Це не дало жодних змін — проблема із перезавантаженнями залишилася. Батарейка CMOS справна. Після цього виконав повне перевстановлення системи через Service OS (SVOS PL.01.09.0003). Послідовність дій: Відформатував пам'ять eMMC. Запустив апаратну діагностику командами diag quickmemtest та diag fruread. Обидва тести завершилися зі статусом PASS. Підключив USB-накопичувач з офіційним образом ArubaOS-CX. Повторно встановив систему в розділ Primary командою: update primary /mnt/usb/ArubaOS-CX_6100-6000_10_09_1031.swi Перевірка образу (Verifying image...) та встановлення кореневої файлової системи (Installing Rootfs...) завершилися успішно зі статусом Done. Після перезавантаження проблема не зникла. 3. Аналіз логів послідовної консолі Для детальнішого аналізу процесу запуску підключився до комутатора через послідовну консоль. Виявилося, що поведінка пристрою залежить від режиму завантаження: У режимі Service OS (SVOS) комутатор працює стабільно й самовільно не перезавантажується. Під час запуску основної системи ArubaOS-CX проблема повторюється. У логах консолі є такі повідомлення: Name: ArubaOS-CX Version: PL.10.09.1031 Build Id: ArubaOS-CX:PL.10.09.1031:dea0ef74d35b:202206140343 Build Date: 2022-06-14 04:07:45 UTC Extracting Image... Loading Image... Done. kexec_core: Starting new kernel System is initializing (C) Copyright 2017-2022 Hewlett Packard Enterprise Development LP 6000 login: PHY reset initiated. PHY reset done. reboot: Restarting system Looking for SVOS. Найбільше уваги привертає послідовність повідомлень після появи 6000 login:: система ініціює скидання PHY, завершує його, після чого перезавантажує пристрій. Послідовність виглядає так: Образ системи успішно зчитується та завантажується. Починається запуск ядра Linux. Система переходить до ініціалізації. З'являється повідомлення PHY reset initiated. З'являється повідомлення PHY reset done. Виконується reboot: Restarting system. Аналогічна поведінка спостерігається під час запуску як із розділу Primary, так і з Secondary. 4. Додаткові помилки в логах Після перевстановлення системи в консолі також з'являються повідомлення, пов'язані з systemd-udevd: System is initializing ArubaOS-CX PL.10.09.1031 6000 ttyS0 WARNING! Entering emergency support login mode. This mode is for support use only and the system will not be fully operational. The system must be rebooted to exit this mode. 6000 login: PHY reset initiated. PHY reset done. systemd-udevd[157]: pvnet0: Worker [2665] did not accept message, killing the worker: Connection refused systemd-udevd[157]: pvnet0: Worker [2639] did not accept message, killing the worker: Connection refused systemd-udevd[157]: pvnet0: Worker [2660] did not accept message, killing the worker: Connection refused systemd-udevd[157]: pvnet0: Worker [2662] did not accept message, killing the worker: Connection refused systemd-udevd[157]: pvnet0: Worker [2669] did not accept message, killing the worker: Connection refused systemd-udevd[157]: pvnet0: Worker [2640] did not accept message, killing the worker: Connection refused systemd-udevd[157]: pvnet0: Worker [2634] did not accept message, killing the worker: Connection refused systemd-udevd[157]: pvnet0: Worker [2649] did not accept message, killing the worker: Connection refused systemd-udevd: 4 output lines suppressed due to ratelimiting reboot: Restarting system Також зафіксовано помилку, пов'язану з eMMC: systemd-udevd[155]: mmcblk0p2: Worker [2598] did not accept message, killing the worker: Connection refused reboot: Restarting system Повідомлення про pvnet0 з'являються приблизно в той самий час, що й повідомлення про скидання PHY. Крім того, є помилка, пов'язана з розділом eMMC. Поки що незрозуміло, чи ці повідомлення є причиною перезавантаження, чи вони виникають уже внаслідок збою під час ініціалізації системи. 5. Вимірювання та підозра на несправність BCM54182 Під час подальшої діагностики перевірив опір відносно землі на конденсаторах, пов'язаних із лінією живлення L9. На всіх перевірених конденсаторах отримав приблизно 14 Ом відносно GND. Аналогічне значення спостерігається на керамічних конденсаторах у колі живлення Ethernet PHY BCM54182. На платі також встановлений контролер PoE LTC4270B. Після цього оглянув плату тепловізором. Мікросхема BCM54182 нагрівається значно сильніше, ніж інші компоненти. У центрі корпусу мікросхеми також помітний характерний слід перегріву. Сукупність цих ознак викликає підозру на несправність BCM54182: У логах є повідомлення про ініціалізацію та скидання PHY. Перезавантаження відбувається одразу після повідомлення PHY reset done. У режимі Service OS комутатор працює стабільно. Повторне встановлення системи не допомогло. BCM54182 нагрівається помітно сильніше за інші компоненти. На корпусі мікросхеми є видимий слід перегріву. Водночас поки що не вдалося остаточно встановити, чи є BCM54182 безпосередньою причиною проблеми. Не виключаю несправність ланцюгів живлення PHY, обв'язки мікросхеми або іншого вузла плати. 6. Подальші дії та запитання до спільноти Знайшов BCM54182 приблизно за 49,35 долара США: https://www.ebay.com/itm/296785907964 Технічно можу самостійно демонтувати мікросхему та встановити нову, але перед цим хотілося б звузити коло можливих несправностей. Також є ризик втратити гарантію після втручання в плату.

А як з ним працювати?

Маю в ремонті Hewlett Packard Enterprise Aruba 6000 48G. Процесор поки не знімав і під радіатор не заглядав. Мікросхеми, які встановлені на платі: 5M1270ZF256C5N NAND: THGBMJG7C1LBAIL SPI Flash: 25Q128 Після ввімкнення свіч нормально працює приблизно 3 хвилини. Після цього загоряються всі світлодіоди на передній панелі й пристрій перезавантажується. Після перезавантаження знову намагається завантажитися, і знову відбувається перезавантаження. Після кількох таких циклів він уже запускається без чергового перезавантаження, але наче зависає — повністю завантажитися не може. Пробував замінити блок живлення на завідомо справний — це не допомогло. Кнопка Reset реагує — якщо її утримувати, налаштування скидаються, але на поведінку свічa це ніяк не впливає. Також пробував відключати живлення портів 54 В, але свіч все одно перезавантажується. Оскільки маю кілька повністю справних свічів цієї ж моделі, зчитав вміст SPI Flash зі справного пристрою та прошив ним несправний. На жаль, це нічого не змінило — проблема залишилася точно такою самою. Батарейка CMOS — справна. Тому не зовсім розумію, де далі шукати причину. Чи є в цій моделі можливість підключитися через консоль/термінал, щоб побачити, на якому етапі завантаження виникає збій? Чи можна якимось чином побачити код помилки або лог перед перезавантаженням? Основна прошивка, наскільки я розумію, знаходиться в NAND. Можливо, є якийсь штатний спосіб увійти в bootloader або recovery, щоб подивитися, на чому саме зупиняється процес завантаження? Можливо, хтось має досвід ремонту таких Aruba і підкаже, де шукати консольний інтерфейс та як правильно підійти до діагностики? Буду вдячний за будь-які підказки — особливо куди підключатися, як переглянути процес завантаження та помилки і що в першу чергу перевірити.

На столі ремонтую оригінальний блок живлення з парт-номером 098-30656-02 від мережевого комутатора Aruba 6000 (вихідні лінії 54V PoE та 12V). Model APD NW-460B01 зібраний на мікросхемах APD201 / APD101. На виході є дві основні лінії: 12V і ±58V. Жодних окремих керувальних сигналів або зовнішнього керування для запуску блока немає: у справному БЖ після підключення до мережі обидві вихідні лінії з'являються одразу (перевіряв на справному блоці). Симптоми: після ввімкнення починається циклічний перезапуск. Реле плавного пуску, яке шунтує позистор, постійно клацає. У момент спрацьовування реле вихідні напруги просідають: лінія 54V падає до 52V, а лінія 12V — до 11,6V. Окремою платкою встановлений БЖ на 12V. Проблема проявляється однаково як із навантаженням, так і на холостому ходу. Підставляв свідомо справний БЖ — сам комутатор Aruba працює штатно. На мережевому конденсаторі PFC стабільно тримається 410V, без провалів. Силові транзистори, діодні збірки, ключі, а також усі електролітичні конденсатори й резистори ланцюга плавного пуску/реле повністю перевірені — усе справне. Реле плавного пуску також справне. У ланцюзі зворотного зв'язку стоїть контролер ST103AIW (Dual OpAmp SOIC-8). Живлення ST103AIW на 8-й ніжці (VCC) нестабільне — плаває від 14 до 15V у такт із клацаннями реле. Фільтрувальний електролітичний конденсатор по VCC справний. Замір на 3-й ніжці (In 1+) ST103AIW показав цікаву поведінку: спочатку там присутні необхідні 2,5V, але щойно торкаюся цієї ніжки мультиметром, напруга миттєво просідає до 0,4V, і генерація на виході БЖ повністю зривається — вихідна напруга стає 0V. Підкажіть, чи стикався хтось із подібною проблемою в ланцюгах подільника зворотного зв'язку на ST103? Заздалегідь дякую за поради! Також замінив мікросхему APD101, вона ж NCP1618A. Заміна нічого не дала. Порівняв опір у дуже багатьох точках між несправним і справним БЖ — усе ідентично. Конденсатори також перевірив.

Замонтували.

В наявності

Вирішив докупити ще дві панелі, щоб загалом було шість. Спочатку стояли 4 × Longi Solar LR5-54HTH-435M, але таких уже не знайшов, тому взяв 2 × Jinko Solar JKM-445N-54HL4R-V. Підключив усе до SRNE HF2430S60-100 і виявилося, що панелі все ж дуже різні. При відключеному виході від панелей на холостому ходу нова пара Jinko віддає приблизно 2 А у старі Longi (міряли струмовими кліщами), тоді як між двома однаковими секціями Longi лише близько 0,13 А. Схоже, панелі працюють одна проти одної, а не разом. У результаті знайшов для себе інше рішення. Колега запропонував EASUN iSolar SMH III 4.2 кВт (24 В) приблизно за 5 тис. грн разом із Wi-Fi модулем. Планую підключити всі шість панелей послідовно, оскільки інвертор високовольтний і підтримує до 6,8 кВт сонячних панелей. З плюсів — два виходи 220 В, можливість роботи без акумулятора (хоча я б так не ризикував) та підмішування енергії з мережі. Номінально він на 4,2 кВт, але для тривалого навантаження я б орієнтувався максимум на 3 кВт. З мінусів — це, по суті, клон Voltronic Power Axpert, та й якість збірки, судячи з усього, не найкраща. Але за такі гроші варіант виглядає доволі цікавим. Буду тестувати. SRNE залишаю собі, бо він уже перевірений і надійний, а EASUN розглядаю більше як недорогий експеримент. Сподіваюся, таке рішення дозволить нормально використовувати всі шість панелей без проблем, які виникли через змішування Longi та Jinko.

Продам.

Після заміни ULN2003 працює. Тестую

В наявності

В наявності

управління на LM324,ULN2003,проц під клеєм.

Luxeon UPS-800WM. При вхідній напрузі 220 В на виході 260 В. Якщо вхідна напруга падає до 170 В, на виході 220 В. Від акумулятора стабільно тримає 220 В. Замінено кілька реле, які мали підвищений опір у замкненому стані — без результату. При регулюванні вхідної напруги ЛАТРом у діапазоні ~160–230 В реле клацає лише один раз. Перевірив усе, що зміг, конденсатори замінені. https://youtu.be/JLKSvjAAQYM

250грн за штуку.

Залищилося 5шт всього