программатор отладчик чипов производства 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 в сети под разные серии.

Приведу переведенный переводчиком перевод главного окна программы:

 

Про протокол общения инструмента прошивки с целевым микроконтроллером.

Если судить по диаграммам логического анализатора снятого при нажатии кнопки на борту "прошивка" то частота сигналов 25мгц. При этом он не совпадает совершенно с классическим I2C (IIC). Значит тут "матрешка" - аппаратно и электрически это I2C а дальше bitbangin' получаем Sequence.

Я выделил четко 3 фазы наблюдая за процессом:

1. Что-то типа Lead-In. предварительный маркер старта коммуникации или чего-то типа хендшейка переводя обычный штатный функционал в режим работы с прошивальщиком\отладчиком.
2. Механизм типа ChipID. Где по всей видимости прошивальщик проверяет что целевой чип подходит под образ прошивки.
3. Сам процесс задувания прошивки внутрь МК. Тут хорошо видно плотный поток в течении примерно 6ти секунд по SCL и "короткие" (по всей видимости подтверждающие /crc) пакеты ответы от устройства по шине SDA.

Все три состояния чуть более детальнее на диаграммах ниже

1.

 

 2.

 

3.

 

Это похоже на нечто типа Time-slot based protocol. А-ля 1 Wire (Maxim Semiconductor). или SWIM (ST Microelectronics). Есть преамбула, есть явно перевод I2C GPIO в особенный режим. и точно есть последовательности жестко по времени формированные.

• Длительность слота по SDA-линии всегда 548uS +-0.1uS. Длительность "пропуска" 19.6uS
• Длительность слота по SCL-линии всегда 13mS +-0.001ms. Длительность "пропуска" 7.1mS
• Длительность между концом передачи по SDA и началом по SCL длинного пакета всегда 52uS +-0.5uS
• Длительность между концом передачи по SCL и началом по SDA пакета всегда 6.6mS

Возможно, пропуски вызваны не самим протоколом а задержкой на расчет внутри прошиваемого MCU некоей контрольой суммы и запись блока в ячейку ПЗУ.

 

Ниже два увеличенных отрезка диаграммы двух разных "посылок-обменов" по линиям:

Что-то типа "преамбулы" совпадает в обоих случаях. а вот дальше различия уже.

Кстати, нажав в интерфейсе программы прошивания кнопку verify несколько секунд идет обмен данными но по результату в окне явно красненьким какая-то ошибка возникает. Само устройство 3 раза моргает красным светодиодом. Т.е. "тут какая-то ошибка". Верификация не проходит, но залитая прошивка работает. Пока осталось это непонятным. Проблема еще в том что шрифт которым пишутся ошибки какой-то особенный китайский и поскольку его нету в установленной у меня ОС то сообщения содержат не иероглифы а вообще мусор и никак не переводятся.

 

Итога тут никакого нет. просто рассказ об инструменте прошивки и отладки программ для 8-ми битных микроконтроллеров CACHIP из Китая.