Поведение, при котором устройство отключается ровно через 20 секунд и не реагирует на пульт ДУ, обычно указывает на то, что ЦПУ сбоит во время загрузки операционной системы/основного кода, либо срабатывает аппаратная защита (блока питания/инвертора/светодиодов), которая отключает вывод Power-On / PS-ON.
Поскольку вы заменили SoC MStar MST6M48RHS и микросхемы EEPROM (24C02/24C08), прошивка или скрытая аппаратная неисправность всё ещё нарушают цикл загрузки.
**Ключевые диагностические тесты**
**Чтение и запись SPI Flash (MX25L3205 - 4MB)** Основной код MStar находится в MX25L3205, а не в микросхемах памяти 24CXX (которые хранят только пользовательские параметры и настройки геометрии). Если память SPI имеет деградировавшие секторы или повреждённые данные, микропроцессор загружает bootloader (загрузчик), но уходит в перезагрузку по сторожевому таймеру (watchdog reset) или сбоит при попытке инициализации панели. Извлеките MX25L3205 с помощью программатора (CH341A, RT809F или аналогичного), сделайте резервную копию (дамп), выполните полное очищение (Chip Erase), убедитесь, что микросхема пуста (0xFF), и заново запишите чистый дамп либо замените микросхему на полностью новую SPI Flash.
**Детекция просадки напряжений вторичных источников (LDO / DC-DC)** Измерьте параметры линейных регуляторов и DC-DC преобразователей вокруг процессора MStar непосредственно перед и во время отключения (от 0 до 20 секунд):
* **1.2V / 1.26V:** Питание ядра SoC (VCORE). * **2.5V / 3.3V:** Питание ОЗУ/логики и SPI Flash (VCC_SPI Вывод 8). * **5V Standby / Main:** Основная линия питания.
Если любая из этих шин проседает или имеет чрезмерные пульсации (ripple) из-за высохших конденсаторов в линии 1.2V VCORE, ЦПУ прекращает выполнение программы через несколько секунд после начала интенсивной загрузки панели.
**Отключение защиты инвертора / подсветки** Отключите разъём инвертора/LED-драйвера или кабель LVDS, идущий к панели T460HVN02. Если плата остаётся включённой дольше 20 секунд без подключённого экрана, проблема заключается не в прошивке, а в защите (OVP/OCP), сработавшей в блоке подсветки экрана, или в неисправности вторичного источника питания.
**Мониторинг через последовательный порт (UART Console)** Чип MStar передаёт лог загрузки (debug log) через TX/RX TTL на скорости 115200 бод (обычно выведен на контакты VGA или на 3-пиновый разъём рядом с MStar). Подключение адаптера USB-TTL (FTDI/CH340) позволяет увидеть в терминале точное место, где происходит сбой последовательности запуска (например, Flash CRC error, Panel init error, Kernel panic).
**Альтернативный поиск прошивки** Шасси SX_200_V1.5 устанавливалось под различными китайскими брендами и местными сборщиками (Konka, TCL, AOC и др.). При поиске бинарного файла SPI фильтруйте запрос по точному сочетанию контроллера и панели:
* Ключевой запрос для поиска: `"MST6M48RHS" + "T460HVN02" dump bin`.
Если дамп от идентичной платы не находится, вы можете использовать совместимый дамп от той же архитектуры MStar MST6M48 с тем же типом памяти SPI и разрешением экрана FHD (1920x1080 LVDS 2-ch 10-bit), чтобы проверить, будет ли система удерживать питание во включённом состоянии.
Это было в пятницу вечером, и в мастерской, казалось, всё шло гладко, пока не принесли 42-дюймовый Smart TV с классической проблемой «циклической перезагрузки» (bootloop). Он включался, показывал логотип бренда секунд на пять, выключался и снова начинал всё заново. Предварительный диагноз: повреждение прошивки в микросхеме памяти SPI Flash.
Первоначальный план был прост: скачать официальный файл `.bin`, записать его на флешку, отформатированную в FAT32, вставить её в сервисный USB-порт и включить телевизор, удерживая кнопку питания для принудительного обновления.
И вот тут началась эпопея.
Телевизор просто игнорировал флешку и продолжал перезагружаться. Попробовав три разные флешки (потому что в электронике мы всегда первым делом виним USB-накопитель), пришлось перейти к «Плану Б»: прямому аппаратному программированию.
Я разобрал устройство, нашел материнскую плату (mainboard) и с помощью термовоздушной паяльной станции выпаял 8-пиновую микросхему SPI Flash в корпусе SOIC-8. Поместил её в адаптер USB-программатора (классический CH341A) и подключил к ПК.
Первым сюрпризом стало то, что софт программатора не определил chip автоматически. После ручного выбора точной модели SPI Flash и чтения содержимого я заметил, что дамп состоит из блоков с нулями и битыми данными. Я приступил к стиранию чипа, но программа выдала досадную ошибку «Erase timeout error».
Проблема была не в памяти и не в файле: 1. Нестабильное напряжение: CH341A выдает 3.3 В на линиях данных, но память требовала более строгих допусков по питанию 3.3 В под нагрузкой, из-за чего процесс записи сбрасывался ровно на 45%. 2. Неподходящая прошивка для панели: я нашел три версии прошивки для одной и той же материнской платы, но оказалось, что эта плата использовалась с двумя разными матрицами (экранами) в зависимости от партии.
Чтобы решить проблему: * Я добавил развязывающий конденсатор по линии питания программатора и запитал микросхему от внешнего регулируемого источника для идеального питания. * С чистым питанием память стёрлась и записалась на 100% с первой попытки. * Я запаял память обратно на плату, подключил шлейфы панели и включил TV.
Телевизор включился... но изображение было перевернуто вверх ногами и с инвертированными цветами (режим MESA/JEIDA)! Мне пришлось войти в сервисное меню платы с помощью оригинального пульта (`Menu + 1147`), перейти к настройкам панели, исправить параметр Mirror Mode и настроить тип маппинга LVDS.
В итоге то, что казалось 10-минутным обновлением через USB, превратилось в трехчасовую смену с фэном, микроскопом и скрытым сервисным меню. Но, конечно, ничто не сравнится с удовлетворением от вида четкого экрана после борьбы с микросхемой.