Bonn miami 081113 rev 02 схема

Samsung AA-PB9NC6B — аккумулятор для ноутбука

Сегодня мы рассмотрим аккумулятор Samsung AA-PB9NC6B, со всех сторон, затем разберем его полностью, заглянем что внутри — какие в нем использованы батареи, какая там плата электроники.

Литиево-ионная аккумуляторная батарея Samsung AA-PB9NC6B является очень распространенной и подходит к большому количеству разных моделей ноутбуков производства Samsung. При правильной эксплуатации она может прожить года четыре и выдержать до 400-450 циклов заряда/разряда.

Итак, Samsung AA-PB9NC6B обычная батарея, легкая, одна сторона выступает как часть корпуса ноутбука. На стороне контактов имеются два фиксирующих выступа. Контактная площадка имеет восемь углублений, но контактов семь — одно углубление просто направляющая и так же для фиксации батареи в ноутбуке. На внутренней стороне две наклейки: одна со штрих-кодом, там же указан серийный номер изделия и его ревизия — REV 1.0. На большой наклейке логотип Samsung, название изделия — Rechargeable Li-Ion Battery. Параметры аккумулятора: DC11.1V постоянного тока, 48Wh или 4400mAh. Название модели, или Product ID: AA-PB9NC6B. A/S: 1588-3366. Указание производителя — Battery cells made in Korea, Assembled in China, что означает — элементы питания сделаны в Корее, сборка в Китае. Потому половина надписей на этом аккумуляторе сделаны корейскими иероглифами. Далее идут предупредительные надписи и значки сертификаций и соответствия международным стандартам качества и безопасности. Значок — не утилизировать с бытовыми отходами.

+ Щелкните по рисунку, чтобы увеличить!

Теперь приступим к разборке Samsung AA-PB9NC6B. Верхняя сторона, где наклейки, съемная и держится на защелках. Сняв эту крышку, видим внутри сборку из шести цилиндрических аккумуляторов, соединенных между собой. Они все соединяются на одной маленькой плате электроники — через два провода красного и черного цветов и через две пластины (на фото от них только хвостики — остальное обрезано). Внутри видим еще одну наклейку со штрих-кодом и цифробуквенным обозначением: 7RAA05FN5B05A-AC9-0661-2E BN. Каждый элемент обтянут зеленой пленкой и на ней нанесена маркировка: ICR18650-22F SAMSUNG SDI 1AB4. Если снять пленку, то на корпусе найдем такие маркировки: H5AB 7N5B1 и N2B9. В общем, намаркировали не жалея краски!

+ Щелкните по рисунку, чтобы увеличить!

+ Щелкните по рисунку, чтобы увеличить!

Теперь вытащим плату электроники и посмотрим чего на ней интересного есть.

Плата маленькая — 108 на 16 мм. Основная масса элементов сконцентрирована на одной стороне платы, там же распаян и разъем. Тут мы видим микросхемы: Q1, Q3 — TPC8118 транзисторная сборка, микросхема IC3 — маркировка залита лаком и маркировка нечитаемая. 12AH3 — на плате он помечен как F1 — это миниатюрный предохранитель. Микросхема IC2 — 20020 A36A и еще одна M37512 — они частично залиты лаком и поверх еще пропечатаны краской «4» на первой и «В» на второй (так что маркировку очень плохо можно разглядеть, могу и ошибаться). Последняя микросхема — микроконтроллер, в котором прошивка на батарею.

+ Щелкните по рисунку, чтобы увеличить!

+ Щелкните по рисунку, чтобы увеличить!

На обратной стороне платы крупных элементов нет, только некоторое количество деталей SMD монтажа. С этой стороны платы припаян температурный датчик на двух проводках — он контролирует нагрев элементов аккумулятора. На плате с этой стороны нанесена маркировка: Bonn_Miami 081113_Rev02. И на белом поле пропечатано BAC2 1 DHF.

Значит, с аккумуляторной батареей Samsung AA-PB9NC6B разобрались. На этом все.

Михаил Дмитриенко, Алма-Ата, 2014 г.

· Опубликовал wasp August 09 2014 · В Ноутбуки, десктопы, мобильное · 0 Комментариев · 24033 Прочтений ·
Комментарии
Нет комментариев.
Добавить комментарий
Пожалуйста, авторизуйтесь для добавления комментария.
Авторизация

Вы не зарегистрированы?
Нажмите здесь для регистрации.

Забыли пароль?
Запросите новый здесь.

Источник

Схема контроллера литий-ионного аккумулятора

Устройство и принцип работы защитного контроллера Li-ion/polymer аккумулятора

Если расковырять любой аккумулятор от сотового телефона, то можно обнаружить, что к выводам ячейки аккумулятора припаяна небольшая печатная плата. Это так называемая схема защиты, или Protection IC.

Из-за своих особенностей литиевые аккумуляторы требуют постоянного контроля. Давайте разберёмся более детально, как устроена схема защиты, и из каких элементов она состоит.

Рядовая схема контроллера заряда литиевого аккумулятора представляет собой небольшую плату, на которой смонтирована электронная схема из SMD компонентов. Схема контроллера 1 ячейки («банки») на 3,7V, как правило, состоит из двух микросхем. Одна микросхема управляющая, а другая исполнительная – сборка двух MOSFET-транзисторов.

На фото показана плата контроллера заряда от аккумулятора на 3,7V.

Микросхема с маркировкой DW01-P в небольшом корпусе – это по сути «мозг» контроллера. Вот типовая схема включения данной микросхемы. На схеме G1 — ячейка литий-ионного или полимерного аккумулятора. FET1, FET2 — это MOSFET-транзисторы.

Цоколёвка, внешний вид и назначение выводов микросхемы DW01-P.

Транзисторы MOSFET не входят в состав микросхемы DW01-P и выполнены в виде отдельной микросхемы-сборки из 2 MOSFET транзисторов N-типа. Обычно используется сборка с маркировкой 8205, а корпус может быть как 6-ти выводной (SOT-23-6), так и 8-ми выводной (TSSOP-8). Сборка может маркироваться как TXY8205A, SSF8205, S8205A и т.д. Также можно встретить сборки с маркировкой 8814 и аналогичные.

Вот цоколёвка и состав микросхемы S8205A в корпусе TSSOP-8.

Два полевых транзистора используются для того, чтобы раздельно контролировать разряд и заряд ячейки аккумулятора. Для удобства их изготавливают в одном корпусе.

Тот транзистор (FET1), что подключен к выводу OD (Overdischarge) микросхемы DW01-P, контролирует разряд аккумулятора – подключает/отключает нагрузку. А тот (FET2), что подключен к выводу OC (Overcharge) – подключает/отключает источник питания (зарядное устройство). Таким образом, открывая или закрывая соответствующий транзистор, можно, например, отключать нагрузку (потребитель) или останавливать зарядку ячейки аккумулятора.

Давайте разберёмся в логике работы микросхемы управления и всей схемы защиты вцелом.

Защита от перезаряда (Overcharge Protection).

Как известно, перезаряд литиевого аккумулятора свыше 4,2 – 4,3V чреват перегревом и даже взрывом.

Если напряжение на ячейке достигнет 4,2 – 4,3V (Overcharge Protection VoltageVOCP), то микросхема управления закрывает транзистор FET2, тем самым препятствуя дальнейшему заряду аккумулятора. Аккумулятор будет отключен от источника питания до тех пор, пока напряжение на элементе не снизится ниже 4 – 4,1V (Overcharge Release VoltageVOCR) из-за саморазряда. Это только в том случае, если к аккумулятору не подключена нагрузка, например он вынут из сотового телефона.

Если же аккумулятор подключен к нагрузке, то транзистор FET2 вновь открывается, когда напряжение на ячейке упадёт ниже 4,2V.

Защита от переразряда (Overdischarge Protection).

Если напряжение на аккумуляторе падает ниже 2,3 – 2,5V (Overdischarge Protection VoltageVODP), то контроллер выключает MOSFET-транзистор разряда FET1 – он подключен к выводу DO.

Далее микросхема управления DW01-P перейдёт в режим сна (Power Down) и потребляет ток всего 0,1 мкА. (при напряжении питания 2V).

Тут есть весьма интересное условие . Пока напряжение на ячейке аккумулятора не превысит 2,9 – 3,1V (Overdischarge Release VoltageVODR), нагрузка будет полностью отключена. На клеммах контроллера будет 0V. Те, кто мало знаком с логикой работы защитной схемы могут принять такое положение дел за «смерть» аккумулятора. Вот лишь маленький пример.

Миниатюрный Li-polymer аккумулятор 3,7V от MP3-плеера. Состав: управляющий контроллер — G2NK (серия S-8261), сборка полевых транзисторов — KC3J1.

Аккумулятор разрядился ниже 2,5V. Схема контроля отключила его от нагрузки. На выходе контроллера 0V.

При этом если замерить напряжение на ячейке аккумулятора, то после отключения нагрузки оно чуть подросло и достигло уровня 2,7V.

Чтобы контроллер вновь подключил аккумулятор к «внешнему миру», то есть к нагрузке, напряжение на ячейке аккумулятора должно быть 2,9 – 3,1V (VODR).

Тут возникает весьма резонный вопрос.

По схеме видно, что выводы Стока (Drain) транзисторов FET1, FET2 соединены вместе и никуда не подключаются. Как же течёт ток по такой цепи, когда срабатывает защита от переразряда? Как нам снова подзарядить «банку» аккумулятора, чтобы контроллер опять включил транзистор разряда — FET1?

Дело в том, что внутри полевых транзисторов есть так называемые паразитные диоды – они являются результатом технологического процесса изготовления MOSFET-транзисторов. Вот именно через такой паразитный (внутренний) диод транзистора FET1 и будет течь ток заряда, так как он будет включен в прямом направлении.

Если порыться в даташитах на микросхемы защиты Li-ion/polymer (в том числе DW01-P, G2NK), то можно узнать, что после срабатывания защиты от глубокого разряда, действует схема обнаружения заряда — Charger Detection. То есть при подключении зарядного устройства схема определит, что зарядник подключен и разрешит процесс заряда.

Зарядка до уровня 3,1V после глубокого разряда литиевой ячейки может занять весьма длительное время — несколько часов.

Чтобы восстановить литий-ионный/полимерный аккумулятор можно использовать специальные приборы, например, универсальное зарядное устройство Turnigy Accucell 6. О том, как это сделать, я уже рассказывал здесь.

Именно этим методом мне удалось восстановить Li-polymer 3,7V аккумулятор от MP3-плеера. Зарядка от 2,7V до 4,2V заняла 554 минуты и 52 секунды, а это более 9 часов ! Вот столько может длиться «восстановительная» зарядка.

Кроме всего прочего, в функционал микросхем защиты литиевых акумуляторов входит защита от перегрузки по току (Overcurrent Protection) и короткого замыкания. Защита от токовой перегрузки срабатывает в случае резкого падения напряжения на определённую величину. После этого микросхема ограничивает ток нагрузки. При коротком замыкании (КЗ) в нагрузке контроллер полностью отключает её до тех пор, пока замыкание не будет устранено.

Источник

Вытаскиваем ПО из запароленного микроконтроллера Renesas M16C

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

Подопытным оказался M306N5FCTFP. Это микроконтроллер группы M16C/6N5. Ядро M16C/60 разработано Mitsubishi, а т.к. преемником этой компании по части МК с 2003 года является Renesas, то сейчас эти микроконтроллеры известны именно под этим брендом.

Немного о самом микроконтроллере

Камешек представляет собой 16-разрядный микроконтроллер в 100-выводном QFP корпусе. Ядро имеет 1 МБайт адресного пространства, тактовая частота 20МГц для автомобильного исполнения. Набор периферии так же весьма обширный: два 16-разрядных таймера и возможность генерации 3-фазного ШИМ для управления моторами, всякие UART, SPI, I2C естественно, 2 канала DMA, имеется встроенный CAN2.0B контроллер, а также PLL. На мой взгляд очень неплохо для старичка. Вот обзорная схемка из документации:

Так как моя задача выдрать ПО, то так же весьма интересует память. Данный МК выпускался в двух вариантах: масочном и Flash. Ко мне попал, как выше уже упоминалось, M306N5FCTFP. Про него в описании сказано следующее:

  • Flash memory version
  • 128 KBytes + 4K (дополнительные 4K — так называемый блок А в подарок пользователю для хранения данных, но может хранить и программу)
  • V-ver. (автомобильное исполнение с диапазоном +125°C)

Как вытащить из устройства то, что разработчики втащили

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

Как видно из картинки выше, память разбита на 2 части: пользовательская область, и область загрузчика. Во второй как раз с завода залит загрузчик по умолчанию, который умеет писать, читать, стирать пользовательскую память и общается через асинхронный, синхронный, либо CAN-интерфейс. Указано, что он может быть переписан на свой, а может быть и не переписан. В конце концов это легко проверяется попыткой постучаться к стандартному загрузчику хотя-бы через UART… Забегая вперед: производитель отопителя не стал заморачиваться своим загрузчиком, поэтом копать дальше можно в этом направлении. Сразу оговорюсь, что есть еще способ параллельного программирования, но т.к. программатора для этого у меня не было, я не рассматривал этот вариант.

Вход в режим работы загрузчика обеспечивается определенной комбинацией на входах CNVSS, P5_0, P5_5 во время аппаратного сброса. Дальше либо написать свою утилиту для копирования содержимого памяти, либо использовать готовую. Renesas предоставляет свою утилиту, которая называется «M16C Flash Starter», но функция чтения у нее урезана. Она не сохраняет прочитанное на диск, а сравнивает его с файлом с диска. Т.е. по сути это не чтение, а верификация. Однако есть немецкая свободная утилитка с названием M16C-Flasher, которая вычитывать прошивку умеет. В общем начальный инструментарий подобрался.

О защите от считывания

Все бы было совсем просто, если бы в загрузчике не была предусмотрена защита от несанкционированного доступа. Я просто приведу очень вольный перевод из мануала.

Функция проверки идентификатора

Используется в последовательном и CAN режимах обмена. Идентификатор, переданный программатором, сравнивается с идентификатором, записанным во flash памяти. Если идентификаторы не совпадают, команды, отправляемые программатором, не принимаются. Однако, если 4 байта вектора сброса равны FFFFFFFFh, идентификаторы не сравниваются, позволяя всем командам выполняться. Идентификатор — это 7 байт, сохраненных последовательно, начиная с первого байта, по адресам 0FFFDFh, 0FFFE3h, 0FFFEBh, 0FFFEFh, 0FFFF3h, 0FFFF7h, и 0FFFFBh.

Таким образом, чтобы получить доступ к программе, нужно знать заветные 7 байт. Опять же, забегая вперед, я подключился к МК, используя тот же «M16C Flash Starter» и убедился, что комбинации из нулей и FF не проходят и этот вопрос придется как то решать. Здесь сразу же всплыла мысль с атакой по сторонним каналам. Уже начал прикидывать в голове платку, позволяющую измерять ток в цепи питания, но решил, что интернет большой и большинство велосипедов уже изобретено. Вбив несколько поисковых запросов, довольно быстро нашел на hackaday.io проект Serge ‘q3k’ Bazanski, с названием «Reverse engineering Toshiba R100 BIOS». И в рамках этого проекта автор решал по сути точно такую же задачу: добыча встроенного ПО из МК M306K9FCLR. Более того — на тот момент задача им была уже успешно решена. С одной стороны я немного расстроился — интересная загадка разгадана не мной. С другой — задача превратилась из поиска уязвимости, в ее эксплуатацию, что обещало гораздо более скорое решение.

В двух словах, q3k точно по такой же логике начал изучение с анализа потребляемого тока, в этом плане он был в гораздо более выгодных условиях, т.к. у него был ChipWhisperer, этой штукой я до сих пор не обзавелся. Но т.к. его первый зонд для снятия тока потребления оказался неподходящим и вычленить из шумов что-то полезное у него не получилось, он решил попробовать простенькую атаку на время отклика. Дело в том, что загрузчик во время выполнения команды дергает вывод BUSY, чтобы проинформировать хост о том, занят он, или готов выполнять следующую команду. Вот, по предположению q3k, замер времени от передачи последнего бита идентификатора до снятия флага занятости мог послужить источником информации при переборе. При проверке этого предположения перебором первого байта ключа действительно было обнаружено отклонение по времени только в одном случае — когда первый байт был равен FFh. Для удобства измерения времени автор даже замедлил МК, отключив кварцевый резонатор и подав на тактовый вход меандр 666кГц, для упрощения процедуры измерений. После чего идентификатор был успешно подобран и ПО было извлечено.

Первый блин — граблями

Ха! Подумал я… Сейчас я быстренько наклепаю программку к имевшейся у меня STM32VLDiscovery c STM32F100 на борту, которая будет отправлять код и измерять время отклика, а в терминал выплевывать результаты измерений. Т.к. макетная плата с целевым контроллером до этого подключалась к ПК через переходник USB-UART, то, дабы ничего не менять на макетке, работать будем в асинхронном режиме.

Когда при старте загрузчика вход CLK1 притянут к земле, он понимает, что от него хотят асинхронного общения. Собственно потому я его и использовал — подтяжка была уже припаяна и я просто соединил проводами две платы: Discovery и макетку с целевым M306.

Заметка по согласованию уровней:

Т.к. M16 имеет TTL-уровни на выводах, а STM32 — LVTTL (упрощенно, в даташите подробнее), то необходимо согласование уровней. Т.к. это не устройство, которое, как известная батарейка, должно работать, работать и работать, а по сути подключается разок на столе, то с трансляторами уровней я не заморачивался: выходные уровни от STM32 пятивольтовый МК переварил, в смысле 3 вольта как «1» воспринимает, выходы от М16 подаем на 5V tolerant входы STM32 дабы ему не поплохело, а ногу, которая дергает RESET M16 не забываем перевести в режим выхода с открытым стоком. Я вот забыл, и это еще +2ч в копилку упущенного времени.
Этого минимума достаточно, чтобы железки друг друга поняли.

Логика атакующего ПО следующая:

  1. Устанавливаем соединение с контроллером. Для этого необходимо дождаться, пока завершится сброс, затем передать 16 нулевых символов с интервалом более, чем 20 мс. Это для того, чтобы отработал алгоритм автоопределения скорости обмена, т.к. интерфейс асинхронный, а МК о своей частоте ничего не знает. Стартовая скорость передатчика должна быть 9600 бод, именно на эту скорость рассчитывает загрузчик. После этого при желании можно запросить другую скорость обмена из пяти доступных в диапазоне 9600-115200 (правда в моем случае на 115200 загрузчик работать отказался). Мне скорость менять не нужно, поэтому я для контроля синхронизации просто запрашивал версию загрузчика. Передаем FBh, загрузчик отвечает строкой вроде «VER.1.01».
  2. Отправляем команду «unlock», которая содержит текущую итерацию ключа, и замеряем время до снятия флага занятости.

    Команда состоит из кода F5h, трех байт адреса, где начинается область идентификатора (в моем случае, для ядра M16C, это 0FFFDFh), длина (07h), и сам идентификатор.
  3. Измеряем время между передачей последнего бита идентификатора и снятием флага занятости.
  4. Увеличиваем перебираемый байт ключа (KEY1 на начальном этапе), возвращаемся к шагу 2 до тех пор, пока не переберем все 255 значений текущего байта.
  5. Сбрасываем статистику на терминал (ну или выполняем анализ «на борту»).

Для общения с целевым МК я использовал USART в STM32, для измерения времени — таймер в режиме Input Capture. Единственное, для простоты я измерял время не между последним битом ключа и снятием флага, а между началом передачи и флагом. Причиной было то, что последний бит может меняться, а в асинхронном режиме прицепить вход захвата особо не к чему. В то же время UART аппаратный и время передачи в принципе идентично и ощутимых погрешностей набегать не должно.

В итоге, для всех значений результаты были идентичны. Полностью идентичны. Тактовая частота таймера у меня была 24Мгц, соответственно разрешение по времени — 41,6 нс. Ну ок, попробовал замедлить целевой МК. Ничего не поменялось. Здесь в голове родился вопрос: что я делаю не так, как это делал q3k? После сравнения разница нашлась: он использует синхронный интерфейс обмена (SPI), а я асинхронный (UART). И где-то вот здесь я обратил внимание на тот момент, который упустил вначале. Даже на схемах подключения для синхронного и асинхронного режимов загрузчика вывод готовности назван по-разному:

В синхронном это «BUSY», в асинхронном это «Monitor». Смотрим в таблицу «Функции выводов в режиме Standart Serial I/O»:


«Семён Семёныч…»

Упущенная вначале мелочь завела не туда. Собственно, если в синхронном режиме это именно флаг занятости загрузчика, то в асинхронном (тот, который serial I/O mode 2) — просто «мигалка» для индикации работы. Возможно вообще аппаратный сигнал готовности приемопередатчика, оттого и удивительная точность его поднятия.

В общем перепаиваем резистор на выводе SCLK с земли на VCC, припаиваем туда провод, цепляем все это к SPI и начинаем сначала…

Успех!

В синхронном режиме все почти так же, только не требуется никакой предварительной процедуры установки соединения, упрощается синхронизация и захват времени можно выполнить точнее. Если бы сразу выбрал этот режим сохранил бы время… Я снова не стал усложнять и измерять время именно от последнего бита, а запускал таймер перед началом передачи последнего байта ключа, т.е. включаем таймер и отправляем в передатчик KEY7 (на скриншоте выше, из логического анализатора, видно расстояние между курсорами. Это и есть отсчитываемый отрезок времени).

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

По оси абсцисс у нас количество дискрет счетчика, по оси ординат, соответственно, передаваемое значение ключа. Отношение сигнал/шум такое, что даже никаких фильтров не требуется, прямо как в школе на уроке информатики: находим максимум в массиве и переходим в подбору следующего байта. Первые 6 байт подбираются легко и быстро, чуть сложнее с последним: там просто наглый перебор не проходит, нужен сброс «жертвы» перед каждой попыткой. В итоге на каждую попытку уходит что-то около 400 мс, и перебор идет в худшем случае в районе полутора минут. Но это в худшем. После каждой попытки запрашиваем статус и, как только угадали, останавливаемся. Я вначале вообще просто быстренько ручками перебрал идентификатор, вставляя в excel вывод консоли и строя график, тем более, что это была разовая задача, но уже для статьи решил дописать автоматический перебор, ради красивой консольки…

Конечно, если бы разработчик затер загрузчик (заменил своим), так просто выкрутиться не получилось бы, но в автомобильной электронике частенько МК вообще не закрыты. В частности в блоке управления с другого отопителя, в котором был установлен V850 того же Renesas все решилось подпайкой пары проводов и копированием прошивки штатной утилитой. Это в мире ЭБУ двигателем целые криптовойны. Видимо не нравится производителям явление чип-тюнинга и других видов вмешательства… Хотя это как гонка брони и снаряда — железки круче, дороже, но победителя нет…

Источник

Оцените статью
REMNABOR
Adblock
detector