программатор отладчик чипов производства Shenzen Jinrui technology Co., Ltd (бренд CACHIP)
Разбираясь с zigbee термостатами из моего предыдущего опуса, наткнулся на семейство различных 8битных микроконтроллеров с Intel 8051 совместимой системой команд производства %сабжа%. Помимо этого есть 32битные микроконтроллеры.
Мне попались CA51F3 и CA51F2 семейства. Эти контроллеры характеризуются малым потреблением тока (до 20uA в пиках), способностью работать от 1.8вольта минимального Vcc до 5.5вольт и тактовой частотой до 27мгц.
Прошивной ISP "интерфейс" аппаратно у контроллеров двухпроводной через UART0. Помимо него есть отладочный IIC зацеплен за этот же порт. Совмещенный UART/I2C переключается в режим специальной последовательностью байт "magic sequence".
Изучение привело меня к знанию что прошивать их можно через "фирменный" инструмент который называют в Китайском интернете как "8-bit tool v3.10" и плюс к нему же полагающегося "CACHIP TOOL": исполняемого файла под MS Windows OS со строго Китайским UI в версиях до 4.х. В интернете еще встречаются похожие устройства с двумя именами: U-EC5/U-EC6 (этот отличается от пятого тем что умеет +5в).
Внешний вид инструмента в руках (существуют в природе "синенькие" и "красненькие"). Синенький работает по одному проводу. красный по 2м. Далее описываю именно "красный".
UDP 30.08.2026. Есть третья версия с маленьким TFT дисплеем и возможность хранить несколько прошивок внутри себя.
Инструмент, аппаратно, представляет собой изображенное на диаграмме функциональное устройство:
Разьем USB2.0 через чип конвертор USB<->UART CH340G подключен к центральному сердцу: популярному микроконтроллеру STM32F103. Он является центром всего: принимает поток данных с UART и записывает во внешнюю флеш-память, далее читает оттуда и организует "хардварный" протокол с прицепляемыми MCU. Это обеспечивает "развязку" от операционой системы необходимую для прошивки. ОС не реального времени и критические тайминги иначе никак не соблюсти. Далее к микроконтроллеру зацеплен чип непонятного мне назначения с маркировкой ET7222U. И плюс FLASH память EN25F20-100GCP в которую "заливаются" с Usb-хоста прошивки которые в дальнейшем после нажатия кнопки FLASH на устройстве будут вкатываться через интерфейс I2c на подключенные контроллеры. "Выход" для прошивки идет не напрямую с контроллера а через развязывающий I2C буфер производства Texas Instruments P82B96. Не хватает только гальванической опто-развязки ;) Но беда тут в том что инструмент, увы, может только с +3.3вольт работать уровнями питания. Потому что по схеме коммутации "задающее" напряжение на ножке Vcc у буфера шины P82B96 инструмента потянуто постоянно к +3.3в увы. А просто зацепить его к +5в скажем не представляется легкой очень задачей. дело в том что в процессе "общения" с подключенными MCU устройство дергает питанием по шине Vcc (для этого и нужен по всей видимости цепочка с двумя транзисторами Q1 + Q2 работающими в режиме ключа и управляемые напрямую с ножки STM32).
В частности на Китайском сайте можно встретить упоминаниние что в случае если требуется другие токовые данные (выше 500мА) то следует воспользоваться "внешним" питанием.
Вопрос только в том что внешнее питание, очевидно, надо дергать (т.е. управлять им) с ножки Vcc +3.3 этого инструмента. иначе не сработает весь Sequence. А в ходе работы "инструмент" дергает питание. А для того чтоб дергать "внешним" питанием уже нужен будет PSU с каким-то "внешним" управлением. (продвинутый лабораторный БП с digital входамии управления).
Сам по себе инструмент умеет такую штуку как offline burning. Т.е. когда на него просто от любого USB зарядника дали напряжение и подключив к целевому MCU нажали кнопку программирования и прошили. Без компьютера вообще. Такие штуки умеют некоторые программаторы. Как пример: Microchip PicKit 3/4.
Это действительно бывает удобно т.к. просто и быстро прошивать массово. Например мне нужно было прошить около 10ти устройств смонтированных уже и таскаться везде даже с ноутбуком подлезая не так удобно как изготовить быстрый "штекер" ISP и дальше тыкаться просто им. Процесс прошивки несколько секунд всего после нажатия кнопки!
У инструмента есть индикация базовая его режимов. Приведу цитату переведенную с Китайского в оригинале:
К сожалению есть и ложка дегтя: инструмент не умеет совершенно делать скачивание (чтение) текущего содержимого FLASH у микроконтроллеров подключеных. Такой функции в CACHIP TOOL нет. Зато есть некоторый функционал отладки полезный для разработки на этом MCU. Если поискать хорошо то можно найти комплекты разработки SDK в сети под разные серии.
Приведу переведенный переводчиком перевод главного окна программы:
Про протокол общения инструмента с целевым микроконтроллером.
Для практических опытов был взят MCU CA51F253L3 с некой прошивкой.
Если судить по диаграммам логического анализатора снятого при нажатии кнопки на борту "прошивка" то происходит несколько основных этапов в ходе коммуникации. В ходе первичного этапа 1200bps 8N1 UART протокол, в ходе дальнейшего 115200bps 8N1 UART протокол. По сути порт выведенный под это (UART0 на схемах даташита) он молчит и никак себя не проявлет до принятия на себя специальной комбинации 3х байт последовательно определенное число раз. Плюс это только часть. далее для операций важных нужна будет ключевая пара второго уровня фактически (3 байтовый идентификатор чипа с которым общаетесь).
Диаграмма ниже - верхняя линия SDA (по ней MCU нам откликается очевидно). нижняя SCL (по ней мы шлем MCU команды и данные)
| 1я фаза | Стартует всё с того что начинается отсылка с программатора в сторону МК пачка импульсов. Лишь через некоторое время МК начнет отвечать. Можно выделить четкую минимальную длительность импульса 832-834uS. Путем нехитрых почесываний извилин мы получаем что 1/1200 равно как раз примерно этой цифре. Можно предположить что это UART протокол с символьной скоростью 1200бит. Поставим на то что раз микроконтроллер 8ми битный то передавать будут 8 бит образущих байт. Накладывая декодер мы получаем осмысленные вполне байтовые наборы. |
| 2я фаза | Тут видно происходит момент переключения на другую скорость. Стартует с SCL-линии. Причем ширина минимальная импульса становится тут 8uS. Если повысить символьную скорость декодера UART до 115200 то получим опять отношение 1/115200 и осмысленную коммуникацию. Начало по SCL-линии последовательность 0x55 0x01 0x02 0x03. на это по SDA идет ответ довольно комично-хохмичный: идет последовательность байт от 0x00 до 0xFE. После последнего бита линия подтягивается к верху. Это крайне оригинальный момент ;) Примерно через 174uS по SCL линии идет длинная последовательность байт. начинающающаяся с 0x55 0x86 0x06 0x04 0x00 0x00 0x00 0x80. Запомним эту "шапку". После окончания поднимается к верху линия и через 2.4ms паузы на линии SDA идет последовательность 0xAA 0x03 0x80 0x00 0x00 0x83 после которой по SCL идет большая пачка данных которая начинается уже знакомой последовательности 0x55 0x86 0x06 0x04 0x00 0x00 0x80 0x80. В ней предпоследний байт "шапки" 0x80 вместо 0x00. Далее идет обмен с паттерном сильно шаблонным: по SCL летят данные большими пачками а перед ними по SDA идет знакомая комбинация байт: 0xAA 0x03 0x80 0x00 0x00 0x83 |
| 3я фаза | Вначале идет обмен по обеим линиям между собой. Потом обмен замолкает примерно на 833мс. Вероятнее всего тут идет некая подготовка к заливке большого обьема. Возможно очистка памяти. перед тишиной проходит 2 коммуникации обмена |
| 4я фаза | А теперь похоже наступает фаза передачи огромных обьемов данных. Минимальная длительность импульса таже что у предыдущей - 8uS. значит параметры связи остались теми же. Начинается она с пачки импульсов со знакомой комбинацией байт 0xAA 0x03 0x80 0x00 0x00 0x83 по SDA линии. После нее следует большой обьем данных блока в SCL. причем вспоминаем о "шапке" из фазы 3. Шапка имеет некую постоянную часть и последние 4 байта - изменяются в определенной четко прослеживаемой комбинации. Похоже на смену счетчика адреса данных. в конце нее идет короткий обмен сообщениями опять и на этом снимается питание с МК Vcc линии. |
Ниже диаграммы разных моментов в ходе коммуникации
Скорее всего большие паузы вызваны тем что это не гигагерцовый терморектальный квантовый вычислитель а 8ми битный микроконтроллер который в соответствии с принятыми обработанными последовательностями выполняет во первых перекоммутации внутренней переферии а так-же подготавливается к неким дальнейшим режимам работы.
Кстати, нажав в интерфейсе программы прошивания кнопку verify несколько секунд идет обмен данными но по результату в окне явно красненьким ошибка возникает. Само устройство 3 раза моргает зеленым а потом красным светодиодом. Т.е. "тут какая-то ошибка". Верификация не проходит, но залитая прошивка работает. Если смотреть на лог.анализатор то увидим только высылку "магической последовательности 3х байт" 0xC1 0x83 0x07. Без преамбулы описанной выше. В ответ молчание. Возможно процесс верификации прошивки реализован методом выдачи "назад" байтов прошивки а если стоит бит-блокировки чтения то MCU просто не отвечает на эту команду. Т.е. проверка залитой прошивки выполняется не аппаратно МК самим а "хостом" прошивающим... Но это беглое предположение которое пока осталось неподтвержденным. Проблема еще в том что шрифт которым пишутся ошибки какой-то особенный китайский и поскольку его нету в установленной у меня ОС то сообщения содержат не иероглифы а вообще мусор и никак не переводятся.
Вообще две выделяющиеся последовательности - MCU очевидно подтвеждает готовность к приему очередной пачки данных высылая 0xAA 0x03 0x80 0x00 0x00 0x83 в фазе когда коммуникация идет на 115200bps. А хост инициирует коммуникацию с помощью 0xC1 0x83 0x07.
UPD 30.08.2026: Появилась новая версия CACHIP TOOL v4.1. В ней добавлена во первых поддержка Английского языка во вторых - она умеет обновлять прошивку самого программатора. у меня стояла стоковая v51.60. и в ней очевидно была ошибка допущена в verify команде. поэтому она не могла дождаться ответа от МК. прошив v52 программатор стала видна знакомая последовательность. Сначала битбэнг перевода видимо в специальный режим работы порта а далее знакомая 0xC18307 последовательность 16 раз и на 15м подтверждение от MCU.
Далее ниже исследование протокола и происходящего в процессе обмена сделанный двумя людьми племени homosapiens аж на год позже оригинальной статьи (30.08.2026):
Все коммуникации происходят по паттерну - программатор спросил а МК ответил. Сторона инициации всегда программатор.
Не учитывая обьем RAM микроконтроллера, не стоит задавать огромных размеров чтения чего-либо. и крайне аккуратно относиться к заливке чего-либо что-бы не превышать доступных обьемов.
Команды (правильнее сказать ответы на команды) отсылаемые МК к программатору идут по паттерну кадра
AA LEN PAYLOAD XOR8
пример команды подтверждения приема данных
AA 03 80 00 00 83
это означает:
АА - ответ
03 - длина (payload len). тут размер который прочитать можно далее. в конце отдельно байт контрольки
80 00 00 - три байта те самые содержащие данные от МК
83 - контрольная сумма XOR
Команды которые отсылает программатор к МК идут по паттерну кадра
55 LEN PAYLOAD XOR8
пример команды
55 01 07 06
55 - запрос
01 - длина (payload len). тут размер который прочитать можно далее. в конце отделно байт конольки
06 - контрольная сумма XOR
Как считается контрольная сумма? она считается от всего пакета кроме самого байта контрольной суммы и префикса АА / 55.
Прослеживается четкая команда идентификации чипа (при несовпадении программа программатора ругается что не совпадет тип MCU)
2 байта идентификатора выбранного чипа в программе прошивальщике передаются в МК
55 04 04 20 A0 01 81
CA51F253L3 = 20 A0 01
CA51F253L2 = 20 A1 01
если все ок то МК нам ответит
AA 03 80 00 00 83
если нет то ответит
AA 03 80 01 00 82
Как узнать идентификатор чипа который у вас? по сути надо прочесть область памяти скрытую где-то в нёдрах МК и идентифицируемую как 0x2B в байте назначения что читать\писать. В этой области размером 256 байт лежат много данных среди которых в самом начале будут как два байта идентификатора чипа так и человеческое имя чипа следующее за ним. Назначение других байтов - пока неизвестно.
Система команд от программатора к МК:
55 начало преамбула встречались такие коды (первый байт после размера пейлоада, если считать командой)
01 - запрос который, предположительно, говорит откуда грузиться далее
02 - запрос от МК последовательности от 00 до FE (часть каких-то танцев во время установки соединения)
04 - запрос в котором участвует идентификатор чипа. три байта идентифицируют чип очень похоже. но что она делает непонятно
05 - очистка флеша. второй байт непонятно что. третий байт это маркер как стирать. 45 частично, 01 полностью. далее непонятно что байт значит. далее байт указывающий в секторах (по 128байт каждый) диапазон к стиранию
06 - запись в xram (аргумент байт 04), либо в flash (аргумент байт 28), далее 3 байта это смещение куда писать, далее байт всегда 80 имеющий значение непонятно что. далее сами данные.
07 - похоже очень на команду завершения сессии. она всегда последней идет
08 - запрос чтения содержимого памяти чипа. первый байт указывает что читаем (28 - флеш, 2B некая скрытая область , возможно калибровочная.), байт 00 пустой, два байта адреса откуда читаем, байт указывающий размер сколько прочесть
13 - запрос расчета чексуммы прошивки во флеше. далее два байта размер сколько надо данных проверить (в байтах), далее 4 байта стартовая контрольная сумма. Считается всегда с нулевого адреса флеша
18 - запрос в котором участвует идентификатор чипа. очень похоже это верификация что мы ожидаем чип такой-то и МК проверяет что он тот самый возвращая ок или нет внутренне разрешая запись если ок
В любом варианте со стороны программатора всегда прилетает в сторону МК кусок некоего кода а-ля bootloader который он размещает в области XRAM. Размер этой области зависит от модели МК.
В испытанных тут моделях это 2048 байт. Размер прилетающего от программатора бута примерно 642 байт (для версии V52 прошивки внутри CACHIP TOOL). Без прилетания этой временной прошивки - ничего не работает кроме уже вшитой прошивки на флеше МК.
выделяются 3 основных стадии работы МК:
стадия 1: это так называемая основной мини-загрузчик (Primary boot loader. PBL или по-другому ROM Boot loader RBL). в ней чип ожидает подключения по дебагу IIC либо UART интерфейсу (1200 бод те самые). если нету ничего то он переходит ко второй стадии
стадия 2: это стадия SBL которая применяется когда подключен ISP/IIC отладчик. грузится она из XRAM области куда ее помещает стадия 1 и ремапит память используя SFR
стадия 3: это main user-code исполнение со встроенной флеш памяти МК. исполнение идет с адреса 0x0000
Было испытано несколько процессов в ходе исследований:
проверка прошивки (verify кнопка в CACHIP TOOL утилите):
открываем порт 1200 бод, 8N1 режим. Начинаем туда писать и одновременно подаем питание Vcc +3.3
16 раз последовательность из трех байт C1 83 07
на 16й раз МК говорит нам AA 4F 4B 00 (очевидно подтверждая прием команды)
после чего мы говорим 55 02 01 00 03
теперь нам МК отвечает AA 06 81 00 08 46 32 53 A8
далее пауза 100мс в ходе которой переключается порт на 115200
и мы посылаем 55 01 02 03
МК нам начинает отвечать последовательным перебором байтов от 00 до FE
в конце мы посылаем 55 04 04 20 A0 01 81
после чего МК нам отвечает AA 03 80 00 00 83
теперь мы начинаем слать тот самый бутлоадер. В текущем виде это 5+1 пакет
"шапка" довольно одинаковый паттерн носит
55 86 06 04 00 aa bb 80
байт aa он инкрементируется на единицу каждый фрейм (посылку) после байта bb = 80.
а байт bb он либо 00 либо 80
всего таких больших посылок будут 5 штук. на каждую из которых МК подтверждает ее прием
AA 03 80 00 00 83
далее в сторону МК от программатора посылка на 11 байт (два оставшиеся байта от бутлоадера)
55 08 06 04 00 02 80 80 F3 22 D9
МК отвечает AA 03 80 00 00 83
и на 10 байт (очевидно запрос расчета контрольной суммы)
55 07 13 56 BA 00 00 AD 75 20
далее после этого выдерживается пауза 300мс. после которой первым МК выдает в линию
AA 08 82 00 43 04 00 28 A9 D8 94
похоже что это значение контрольной суммы прошивки юзерной расчитанное из памяти флеша
далее программатор высылает 55 01 07 06
МК отвеает знакомым AA 03 80 00 00 83 и возможно но не факт 00 байт.
на этом питание снимается и коммуникация прекращается вся.
фаза прошивки:
открываем порт 1200 бод, 8N1 режим. Начинаем туда писать и одновременно подаем питание Vcc +3.3
16 раз последовательность из трех байт C1 83 07
примерно на 16й раз МК говорит нам AA 4F 4B 00 (очевидно подтверждая прием команды)
после чего мы говорим 55 02 01 00 03
теперь нам МК отвечает AA 06 81 00 08 46 32 53 A8
далее пауза 100мс в ходе которой переключается порт на 115200
и мы посылаем 55 01 02 03
МК нам начинает отвечать последовательным перебором байтов от 00 до FE
теперь мы начинаем слать тот самый бутлоадер. В текущем виде это 5+1 пакет
"шапка" довольно одинаковый паттерн носит
55 86 06 04 00 aa bb 80
байт aa он инкрементируется на единицу каждый фрейм (посылку) после байта bb = 80.
а байт bb он либо 00 либо 80
всего таких больших посылок будут 5 штук. на каждую из которых МК подтверждает ее прием
AA 03 80 00 00 83
далее в сторону МК от программатора посылка на 11 байт (два оставшиеся байта от бутлоадера)
55 08 06 04 00 02 80 80 F3 22 D9
МК отвечает AA 03 80 00 00 83
далее программатор посылает 55 04 18 20 A0 01 9D
МК нам отвечает AA 03 80 00 00 83
теперь программатор отсылает 55 05 05 28 45 00 AE C3
теперь наступает 822мс пауза...после которой от МК опять последовательность
AA 03 80 00 00 83
теперь мы в сторону МК гоняем большие фреймы с шапкой
55 86 06 28 00 00 00 80 и далее много байт
опять такой же паттерн повторяет 55 86 06 28 00 aa bb 80
байт aa он инкрементируется на единицу каждый фрейм (посылку) после байта bb = 80.
а байт bb он либо 00 либо 80
далее программатор высылает 55 01 07 06
МК отвеает знакомым AA 03 80 00 00 83 и возможно но не факт 00 байт.
на этом питание снимается и коммуникация прекращается вся.
помимо этого в ходе ковыряния был найден секретный 08 код который является запросом операции чтения флеш памяти чипа
доступный к чтению обьем зависит от модели чипа.
во время этого посылается программатором запросы последовательные на вычитывание области памяти флеша. В конце завершается сессия.
В ходе чтения всего обьема доступного памяти МК испытуемого (32кб) были получены интересные данные. у МК присутствуют в конце самом области памяти похожие на NVRAM/EEPROM (128байт) и некая область (с адреса 32512) калибровочных констант (48байт) по всей видимости.
По итогам данного исследования была изготовлена утилита которая имеет важную дополнительную функцию скачивания прошивки с чипа недоступную в оригинальном инструменте. Так-же поскольку утилита написана на Питон языке - она кросс-платформена что открывает дополнительные удобства.
There are no published comments.
New comment