программатор отладчик чипов производства Shenzen Jinrui technology Co., Ltd (бренд CACHIP)
Разбираясь с zigbee термостатами из моего предыдущего опуса, наткнулся на семейство различных 8битных микроконтроллеров с Intel 8051 совместимой системой команд производства %сабжа%.
Мне попались CA51F3 и CA51F2 семейства. Эти контроллеры характеризуются малым потреблением тока (до 20uA в пиках), способностью работать от 1.8вольта минимального Vcc до 5.5вольт и тактовой частотой от 1 до 27мгц.
Прошивной "интерфейс" аппаратно у контроллеров i2c двухпроводной, но "внутри" бегают данные совсем не i2c протокола данные. Они скорее time-based фреймы.
Изучение привело меня к знанию что прошивать их можно через "фирменный" инструмент который называют в Китайском интернете как "8-bit tool v3.10" и плюс к нему же полагающегося "CACHIP TOOL": исполняемого файла под MS Windows OS со строго Китайским UI. В интернете еще встречаются похожие устройства с двумя именами: U-EC5/U-EC6 (этот отличается от пятого тем что умеет +5в).
Внешний вид инструмента в руках (существуют в природе "синенькие" и "красненькие"). Синенький работает по одному проводу. красный по 2м. Далее описываю именно "красный".
Инструмент, аппаратно, представляет собой изображенное на диаграмме функциональное устройство:
Разьем 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 с некой прошивкой.
Если судить по диаграммам логического анализатора снятого при нажатии кнопки на борту "прошивка" то происходит 5 основных этапов в ходе процедуры "заливки". Происходящее никак не совпадает тем что на шине I2C гуляет в обычном режиме.
Значит тут "матрешка": аппаратно и электрически это I2C а дальше bitbangin' получаем Sequence совсем другой переводя порт в другое состояние.
Диаграмма ниже - верхняя линия SDA . нижняя SCL
| 5я фаза | Стартует с SCL-линии. Назвать это простыми прыжками состояния верх\низ - не очень представляется логичным. Пачки импульсов по обеим линиям и потом обе в ноль кладут линии. Ширина импульсов 10,30,40,90,80,140 uS. Продолжительность паузы после окончания сеанса до следующей фазы - 203.8ms. По обеим линиям - одинаковая задержка. Больше нигде нет такой четкой задержки синхронной. |
| 4я фаза | Стартует с SDA-линии. Пачки импульсов с обеих сторон. Можно выделить четкую минимальную длительность импульса 832-834uS. Путем нехитрых почесываний извилин мы получаем что 1/1200 равно как раз примерно этой цифре. Можно предположить что это UART протокол с символьной скоростью 1200бит. Поставим на то что раз микроконтроллер 8ми битный то передавать будут 8 бит образущих байт. Накладывая декодер мы получаем осмысленные вполне байтовые наборы. SCL-линия набивает последовательность 0xC1 0x83 0x07. Которая повторяется ровно 16 раз. Дальше по SDA-линии ей отсылают 0xAA 0x4F 0x48 0x00. После чего SCL-линия выдает 0xC1 0x55 0x02 0x01 0x00 0x03. На этом посылка по линии SCL завершается она подтягивается к верху. SDA-линия набивает 0xAA 0x06 0x81 0x00 0x08 0x46 0x32 0x53 0xA8 и подтягивается к верху. На этом фаза завершается. Пауза до следущей фазы 101.3ms по SDA и 174.4ms по линии SCL |
| 3я фаза | Стартует с SCL-линии. Причем ширина минимальная импульса становится тут 8uS. Если повысить символьную скорость декодера UART до 115200 то получим опять отношение 1/115200 и осмысленную коммуникацию. Начало по SCL-линии последовательность 0x55 0x01 0x02 0x03. на это по SDA идет ответ довольно комично-хохмичный: идет последовательность байт от 0x01 до 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 . Заканчивается все это длинной паузой почти в секунду 822.8ms |
| 1я фаза | А теперь похоже наступает фаза передачи огромных обьемов данных. Минимальная длительность импульса таже что у предыдущей - 8uS. значит параметры связи остались теми же. Начинается она с пачки импульсов со знакомой комбинацией байт 0xAA 0x03 0x80 0x00 0x00 0x83 по SDA линии. После нее следует большой обьем данных блока в SCL. причем вспоминаем о "шапке" из фазы 3. Шапка имеет некую постоянную часть и последние 4 байта - изменяются в определенной четко прослеживаемой комбинации. идут два пакета следующая посылка следующая посылка |
Скорее всего большие паузы вызваны тем что это не гигагерцовый терморектальный квантовый вычислитель а 8ми битный микроконтроллер который в соответствии с принятыми обработанными последовательностями выполняет во первых перекоммутации внутренней переферии а так-же подготавливается к неким дальнейшим режимам работы.
так-же предположение что 5я фаза это преамбула переключающая порт I2C изначальный в режим "некоего UART". сначала в 1200 потом 115200. 3я фаза это так называемая процедура chipID - идентификация чипа. далее 1я фаза это непосредственно сама процедура прошивки.
Кстати, нажав в интерфейсе программы прошивания кнопку verify несколько секунд идет обмен данными но по результату в окне явно красненьким какая-то ошибка возникает. Само устройство 3 раза моргает красным светодиодом. Т.е. "тут какая-то ошибка". Верификация не проходит, но залитая прошивка работает. Пока осталось это непонятным. Проблема еще в том что шрифт которым пишутся ошибки какой-то особенный китайский и поскольку его нету в установленной у меня ОС то сообщения содержат не иероглифы а вообще мусор и никак не переводятся.
Итога тут никакого нет. просто рассказ об инструменте прошивки и отладки программ для 8-ми битных микроконтроллеров CACHIP из Китая.
There are no published comments.
New comment