Доброго дня.
Принесли сабж с проблемой "не включается". Осмотр показал, что ноутбук реагирует на кнопку включения, но индикатор питания загорается на одну-две секунды. При вскрытии обнаружил следы жидкости (совсем мало, буквально капля) и локализовал обрыв в цепи управления источником 1.05В. Устранив проблему запуска всплыла другая - отсутствие инициализации. Я проверил все сигнальные цепи между мультиконтроллером и чипсетом - всё соответствует диаграмме, приведенной в документе с принципиальной схемой. Залил заведомо рабочий дамп BIOS - по нулям. Далее я решил произвести кратковременный прогрев чипсета в течении минуты, однако и этот шаг не принес положительных результатов. Учитывая, что мутиконтроллер обращается к флешке и выдает правильные сигналы для запуска, а также наличие всех необходимых напряжений, я решил заменить чипсет на новый. Однако и замена инчего не дала. Совсем было отчаялся, но вспомнил, что не проверил наличие тактовых сигналов - но и здесь было все в порядке. Последним действием было снятие нового моста и прозвонка многих цепей (клок, управление, LPC...), которая тоже ничего не дала.

Резюмирую: питания есть, считывание флешки есть, сигналы управления с мульта есть, инициализации нет, на шине LPC пусто.
Я не пробовал менять мультиконтроллер, т.к. сразу не заказал, а клиент уже устал ждать.

Помогите пожалуйста советом, опыта не хватает. Может ли в этой ситуации виноват мультиконтроллер? Или все же где-то обрыв из-за некогда попашей влаги?
Заранее благодарю.

Нужно проверить, все ли вторичные напряжения поднимаются. Последовательность запуска указана в схеме на стр. 39
Следуйте ей для определения неисправности, раз механические повреждения платы исключены.
Какое потребление платы?

Кнопка с мульта на юг транслируется?
Юг слипы снимает?

Товарищи, все понимаю, я новичек и могу по не опытности пропустить какие-нибудь диагностические этапы. Но пожалуйста, хотя бы внимательно читайте первый пост, иначе создается впечатление, что ваши сообщения исключительно для накрутки рейтинга.

Итак, как я и указал в первом сообщении, все сигналы соответствуют диаграмме, приведенной в документе с принципиальной схемой. Поднимаются все вторичные напряжения, потребеление платы при этом приблизительно 380мА.

Подключил к шине LPC вот такой вот логический анализатор с максимальной частотой семплирования 200МГц и обнаружил, что после деактивации RSMRST# происходит некоторый обмен информацией между мультиконтроллером и системной логикой. Осциллограф с полосой 50МГц эти сигналы поймать не может Диаграммы, к сожалению, не сохранил, но судя по начальным кадрам - это вполне нормальный процесс считывания микропрограммы (LPC Interface Specification rev1.1). Просматривались поля START, IDSEL, MADDR, MSIZE, TAR... Но вот что меня смутило: в процессе обмена данными тактовый сигнал LCLK не наблюдался, а появлялся гораздо позже, с подачей питания на клокер. При этом каждая часть байта (nibble) сопроваждалась активацией цепи LFRAME#, чего по документации быть не должно было. Может это какая-то модификация протокола общения моста с firmware Hub'ом, может с мостом что-то не так, однако в открытой документации на чисет Intel NM10 указана ссылка на спецификацию LPC ревизии 1.1 (см. ссылку в тексте выше) датированную 2002 годом. Информации свежее я не нашел (хотя и не особо старательно искал).
Кто-нибудь что-нибудь знает о процессе считывания микропрограммы по шине LPC? Я имею ввиду отличия и нововведения относительно описанных в ревизии 1.1.

Совсем отчаявшись попробовал заменить мультиконтроллер и залить биос с официального сайта - результат отрицательный.

К сожалению домучать аппарат не смог, да и желание пропало, отдал без ремонта.

Итак, не добившись результата с сабжевой платой я вернул ее заказчику. Однако, полученные результаты измерений не давали покоя и я решил подключить логический анализатор к заведомо исправной плате. В качестве подопытного была взята плата на базе ЮМ ICH9M от ноутбука Acer Apire 6930G (Quanta ZK2). Организация блоков ЮМ, мультиконтроллера и Flash памяти на этой плате такие же, как и на ZE7, поэтому она вполне подошла для исследования.
На работоспособном примере я выяснил, что считывание микопрограммы происходит только при наличии тактового сигнала и при деактивированных сигналах RSMRST# и PLTRST#. Во время исследования платы Acer AOD270 попытка передачи данных происходила без тактового сигнала ( ), а в цепи PLTRST# был активный уровень. Это может свидетельствовать о неисправности ИМС системной логики (при условии отсутствия обрывов в других цепях).

Ниже на рисунке представлен начальный обмен данными между ICH9M и мультиконтроллером.

Описание протокола передачи данных можно прочитать в документации в свободном доступе (см. ссылку в предыдущем посте). Дам некотоые краткие пояснения.
Передача данных производится кадрами. Начало кадра обозначается установкой цепи LFRAME# (активный низкий уровень). Цепью LFRAME# управляет хост-контроллер и это всегда системная логика. Мультиконтроллер всегда выступает в роли периферийного устройства. Защелкивание данных производится по фронту тактового сигнала.
Диаграмма к сожалению слишком сжата по оси x, т.к. хотел привести более наглядный пример, но разобраться в ней при желании можно. Видно, что каждый кадр начинается с активации линии LFRAME# и содержит поле START с кодом 0xD (0b1101), который соответствует команде Firmware Memory Read. Длина поля START равна одному такту. Далее следует поле IDSEL (Device Select): один такт и значение 0x0. Поле MADDR (Memory address) следует за полем IDSEL и длится семь тактов: в первом кадре передается адрес 0xFFFFFB0. Затем следует поле MSIZE (Memory size): один такт и значение 0x0, соответствующее считыванию одного байта. Следом наблюдаются поля TAR (Turn Around) - передача управления шиной LAD[3:0] периферийному устройству (2 такта) - и много тактов синхронизации (значение поля SYNC - 0x6), очевидно мультиконтроллер подготавливает данные к отправке. Когда данные готовы, мультиконтроллер устанавливает на шину данных значение 0x0 (это по прежнему поле SYNC), а следом данные из ячейки памяти (2 такта) - 0x00. Затем снова следует поле TAR для возврата управления шиной данных хост-контроллеру и завершение кадра.
В следующем кадре хост-контроллер запрашивает данные по адресу 0xFFFFFB1 и получает от мультиконтроллера значение 0x66 уже без задержки. И так далее.

Процес обмена происходит с чатотой тактового сигнала 33МГц и просматривается осциллографом с полосой 50МГц. LPC POST-карта эти данные не отображает, посокльку игнорирует кадры со значением поля START, соответствующим чтению/записи микропрограммы. При измерениях на плате ZE7, по данным ПО логического анализатора, в цепи LFRAME# наблюдалась частота 50МГц и сигнал такой частоты на дешевом осциллографе не удавалось пронаблюдать (вероятно не успевал сработать триггер).