Саундбар который не смог.
Саундбары не самые частые гости мастерской, однако они мне попадаются и зачастую проблемы у них разительно отличаются от типовых "косяков" обычных портативных колонок. Так случилось и с данным устройством, проблема сложная, диагностируется не просто.
Это модель не имеет отношения к Deep Bass как многие могут подумать. Данная модель отличается от своего сородича полностью, т.е. абсолютно. Здесь совершенно другая архитектура и набор микросхем.
Если обратиться к структурной схеме, то станет понятно, на сколько они разительно отличаются.
Итак с чем мы имеем дело? В качестве MCU, или другими словами главного мозга всего устройства, представлен процессор SPHE8107C. Такие мне ещё не попадались, придётся с ним знакомиться. Далее в системе присутствует ЦАП (куда ж без него), в роли которого выступает CS4528. Судя по названию, чип явно от Cirrus Logic, как окажется так и есть. Лично у меня микросхемы этого производителя всегда вызывают лёгкую дрожь, т.к. ничего простого они обычно не обещают. Будет сложно и это правда.
Ну и на закуску. Чип DSP - в его роли CS497014, а значит снова Cirrus Logic. Т.е. оптимизма не прибавилось. Ещё на борту странный Bluetooth модуль ATS2825C с которым так же никогда не имел дело. В общем ситуация становится с каждым мгновением всё "интересней". Для передачи звука в сабвуфер ипользуется радиочастотный приёмо-передатчик от Syncomm.
Что со всего этого? Если сказать что я в замешательстве, это ничего не сказать. Задача выглядит не просто сложной, а почти невыполнимой. Чтобы понять логику работы, придётся поднять не только схему устройства, но и все документы на микросхемы и понять их назначение, разобрать работу и способ подключения в изделии.
Проблема устройства. Проверка питаний.
Саундбар по кнопке включения стартует, появляется надпись ON, через несколько секунд её меняет надпись OPT (что означает активный порт оптического входа), а затем ещё через несколько секунд дисплей гаснет. Иногда мне удавалось вместо OPT получить BT (Блютуз) и даже ARC (HDMI), но причинно-следственных связей найти мне не удалось, почему порт якобы переключается. Хотя возможно, если вместо кнопки питания нажать Источник (надо проверить догадку). Пока саундбар якобы загружается и до момента выключения ни на какие кнопки реакции нет.
Попытка нажать кнопку питания повторно приводит к аналогичному исходу и так можно продолжать до бесконечности. Судя по всему, питание отключается из-за какой-то критической ошибки в ПО или аппаратной ошибки(вероятнее всего). Чтобы понять кто выключает питание после попытки старта, вооружаюсь мультиметром и схемой, чтобы отыскать и проверить управляющие сигналы на ключах подачи питания.
Сигнал SYS_PCON формируется из MCU и именно он же его и отключает после некоторого времени. После подачи управляющего сигнала, появляются необходимые напряжения на плате для работы всех устройств, это линии SYS_5V и SYS_3V3.
Допустив, что возможно пропадает питание самого MCU, я решил проверить его источник. Выяснилось, что он подключен от дежурки STB_3V3, который запитывает MCU через нулевой резистор в точке D_3V3, т.е. всегда активен и мультиметр это подтвердил. Выходит MCU целенаправленно отключает напряжения для всего устройства.
Так же проверил остальные дежурные источники, а так же формирователи рабочих напряжений на всех устройствах и ни одно не вызвало подозрений.
Следующая идея была выяснить, не выдают ли усилители какого-нибудь сигнала ошибки, который может быть интерпретирован MCU как критический, после чего принимает решение обесточить устройство.
Однако сигнал FAULTZ ни один из усилителей не выдаёт, а питание на них присутствует.
Выходит проблему с питанием придётся сразу отбросить. На самом деле это плохо, т.к. решение могло быть самым простым.
Ищем программную проблему.
Предположив, что внезапное отключение на этапе старта может быть вызвано сбоем ПО, хотя это и вызывает лёгкий скепсис, но я решил отыскать наборы прошивок (дампов) от микросхем имеющихся на борту. А здесь их целых 4. Три из них представляют собой микросхемы флеш памяти с интерфейсом SPI, а четвёртая это EEPROM 24 серии.
Почему же их столько на борту? Всё просто: MCU, DSP и Bluetooth не имеют встроенной памяти, их рабочий программный код хранится в соответствующей внешней флеш.
Откровенно говоря из всех представленных на форумах мастеров наборов дампов от данной модели саундбара, мне приглянулся лишь один, но скачал я все. Далее начал по очереди их проливать в микросхемы памяти и пробовать включать устройство.
Как думаю вы уже догадались - никаких изменений не произошло. Но одно понял точно - при заливке "чужого" дампа конкретно в микросхему памяти от MCU (позиция U12), саундбар выключается даже не доходя до индикации активного порта! Это может означать, что в коде присутствуют какие-то критические данные для конкретного экземпляра материнской платы или процессора.
Таким образом, ошибку программную я так же исключил, но пока с пометкой "не уверен".
Проверка главных микросхем.
Самые простые и ожидаемые варианты источника проблемы я проверил, перехожу к более сложным. Постараюсь проверить работу ключевых микросхем, т.е. условный тест на их исправность. Начну пожалуй с простого, проверку чтения соответствующей флеш памяти при запуске. По-скольку как выяснилось все чипы имеют внешнюю память с программным кодом, значит при подаче питания исправная микросхема обязана его считать.
Вооружившись осциллографом, я проанализировал сигналы SPI_CLK на микросхемах памяти. Слушать обмен на микросхеме памяти от MCU смысла нет, он однозначно исправен и стартует, так что перехожу сразу к ЦАП CS42528. Здесь я должен оговориться, в ЦАП загружается только конфиг, который отправляет ему MCU, потому проверке я подверг шину IIC. Осциллограф показал вполне чёткую картину на тактовой линии, затем я подключился к шине данных и там обмен оказался вполне узнаваем. Данные пролетают быстро, считанные секунды во время запуска, что указывает на успешную вероятную загрузку, а значит, можно предположить, что ЦАП исправен как минимум в цифровой части, а значит скорее всего и сам обмен данными между ним и главным процессором тоже будет правильный (исходим из исправности ПО).
Далее я проверил блютуз модуль где обнаружил отличную картину передачи данных между ним и соответствующей памятью. Так же у модуля оказался выведен порт для подключения USB и я не смог отказать себе в удовольствии подключить его к компьютеру.
Быстро распаяв кабель USB, я подключил его в компьютер, но никакой реакции не последовало. Тогда я решил, что дело в ПО и снял флеш блютуз модуля с платы. Это должно заставить процессор ATS2825 (если он исправен) перейти в режим DFU и отобразиться как новое устройство. Так на практике и вышло.
Вердикт - блютуз скорее исправен чем нет.
Ну и напоследок DSP. И вот тут картина оказалась совсем другая. Никакого внятного чтения микросхемы памяти при запуске мне обнаружить не удалось. Только какое-то жалкое тактование на непонятной частоте с непонятной амплитудой, больше похожей на наводки от работы какого-то внутренного модуля/блока.
Следом я разумеется проверил работу тактового генератора (кварцевый резонатор частотой 25 МГц), там всё в порядке. Затем проверил вывод сигнала MCLK (основной тактовый импульс для синхронизации всех устройств участников звукового тракта). Там вменяемая синусоида странной частоты.
Не найдя в описании к процессору значения частот, решил пока не акцентрировать внимание на нём, работает и ладно. Но что-то мне подсказывает, что частота должна быть на уровне нескольких МГц. А что же обмен данными с MCU?
А вот здесь меня ожидало разочарование, данных осциллографом мне увидеть не удалось. Это уже не просто подозрительно, а даже странно.
Зато я внезапно обнаружил ещё одну немаловажную проблему.
У DSP зажат RESET, что означает - он физически не может запускаться при его наличии. Я проследил цепочку и выяснил, что сигнал RESET удерживается и подключен именно к MCU.
Что ж, по какой-то причине процессор отключает DSP не позволяя тому запускаться. Осциллограф дал понять, что в момент подачи питания, MCU некоторое время удерживает высокий уровень, а затем подаёт сигнал Reset и не сбрасывает его до момента отключения питания. Причина такого поведения мне не понятна и я решил проверить, сможет ли DSP загрузиться без участия MCU, для чего я просто снял нулевой резистор R126 с цепочки сброса для DSP.
Однако такой финт так же не привёл к каким-либо изменениям в работе устройства, ни обмена данными с MCU ни чтения флеш у DSP не случилось.
Потратив ещё некоторое время на изучение электрической схемы саундбара, я внезапно наткнулся на порт UART.
Это меня несказанно обрадовало, т.к. я уверен, что он представляет собой отладчик (порт Debug). Действительно, с помощью переходника UART->USB я смог получить данные, которые MCU отправляет в этот порт. Экспериментальным методом я подобрал скорость работы порта в 9 600 Baud (бит/сек).
Но здесь меня ждало разочарование. Какой-то внятной информации я получить не смог. Заметно только логирование кнопки Питания, после чего в порт передаются видимо "сырые" данные, возможно значения регистров или тому подобное в чистом (бинарном) виде. Наверняка специальная программа от разработчика прояснила бы их. В конце лишь снова текстом какие-то значения индексов и отправка команды на отключение питания (Standby mode), точнее переход в режим ожидания. Очевидно, программа не может быть загружена и процессор целенаправленно выключает устройство.
Тупик или приговор для DSP.
На данном этапе я закончил возню с саундбаром и отложил его, временно или нет покажет время. Предварительно я забраковал DSP процессор, так как исчерпал свои знания и возможности к проверке его исправности. Если у вас есть мысли по поводу, буду рад выслушать и подискутировать.
Пишите в комментариях - что вы думаете по этому поводу.