Автономный микропрограмматор BootProg для прошивки boot-а (а может и не только), "Схема" из 5-и деталей + программа. Может заинтересует... Опции

[Dimonira]

Начну с того, для чего это потребовалось и "откуда ноги растут".
Три года назад сделал по заказу девайсы на ATMega16, софт к ним. Девайсы имели интерфейс с компьютером по RS-232 и я заложил в схему возможность запуска boot-загрузчика (перемычку). Но тогда по запарке, а может из экономии денег (не помню точно), заказчик решил не делать boot-загрузчик и прошивать девайсы только программатором. За три года много девайсов разошлось по миру и никому не требовалось что-то менять в девайсах.
Но тут вдруг в Германии нашлись потребители, которые захотели-таки немного "заточить" девайсы под себя. И встал вопрос а как быть? Ну, софт доработать не проблема, а как его заменить в девайсах? И при этом не открыть прошивку, т.е. не отдать её в чужие руки в открытом виде. Ехать кому-то в Германию с программатором, софтом и т.п. накладно. Отдать прошивку (если они сами найдут программатор) нельзя, мало ли что. Девайсы то по железу простые, скопировать раз плюнуть. Просить чтобы прислали девайсы сюда тоже накладно, долго, проблемы таможни и т.д. Что делать?
И тут появилась идея автономного (т.е. без компьютера) микропрограмматора. Это маленькое устройство, которое подключается к разъёму ISP девайса (питается от него же) и программирует его после включения питания. Тогда мы им высылаем этот маленький программатор и они с его помощью "оприходуют" все свои девайсы. Для простоты было решено таки программировать AES-boot загрузчик, а потом уже с компьютера заливать в девайсы новую версию софта (а потом и следующие обновления, если будут). К тому же загрузчик мал по размеру (менее 2К), так что нет проблемы его "запихать" в память контроллера микропрограмматора. Конечно, возможность "перехвата" кода остаётся - если "снять" весь обмен по ISP в момент программирования. Но всё же это потребует некоторых "спец" средств, которых может не быть под рукой. Да и желание "связываться" может отпадёт. Для "надёжности" ещё решено применить счётчик программирований, - задать количество девайсов, которые можно будет прошить микропрограмматором. Счётчик будет в eeprom, декрементироваться после каждого удачного программирования. При обнулении счётчика - в отказ.

Теперь о железе микропрорамматора. Это 5-ть деталей: контроллер ATMega48V (в DIP-корпусе), светодиод, резистор 470 Ом (или около того), панелька 28 ног для контроллера и разъём ISP (в моём случае 6 пин) для втыкания в целевой девайс. Схему тут не привожу, т.к. её рисовать дольше чем написать текстом: выводы земли и питания с ISP разъёма подаются на ноги котроллера 8,22 и 7,20 соответственно; сигналы MOSI, MISO, SCK на одноимённые выводы контроллера - 17,18,19; сигнал RESET - на вывод 16; светодиод катодом на вывод 6 и анодом через резистор на плюс питания (нумерация ног для DIP-корпуса!). Тактирование делается внутренним RC-генератором, на который контроллер "настроен" с завода. Я только сбросил фуз-бит делителя на 8, чтобы контроллер начал работать на тактовой 8 МГц. Панелька нужна для того чтобы вынуть контроллер и зашить его в программаторе. Но можно доработать схему для того чтобы шить контроллер не вынимая, - для этого надо добавить переключатель, который переключает сигнал RESET с разъёма ISP между выводами 16 и 1 контроллера. Я так не делал, чтобы избежать каких-либо проблем с немцами или при пересылке, - вдруг перемычка сорвётся, будет переставлена и т.д., надо чтобы всё было "железно".

Как работает. Подключаем к ISP разъёму, включаем питание целевого девайса, начинается программирование. Поскольку оно очень быстрое, то индикация сделана только "по результатам". Если не удалось войти в режим программирования, то длинная вспышка светодиода и такая же пауза, попытки войти в режим программирования циклически повторяются. Если контроллер девайса не тот, который должен прошиваться (не тот ID кристалла), то короткая вспышка с длинной паузой. Если истёк счётчик прошиваний, то короткая вспышка и короткая пауза. Если всё в норме, то постоянное свечение. В последних трёх случаях микропрограмматор в итоге зацикливается на высветке.

Софт микропрограмматора сделан путём кастрации софта из моей темы про программатор Dimoniprog (тут). Для упрощения все ожидания завершения программирования флеша или фузов с локами сделаны просто на задержках.
Для использования проекта в своих целях надо адаптировать под нужный целевой кристалл (код кристалла, задержки, значения фузов и локов). Это делается настройками определений в начале файла isp.c. У меня всё настроено для программирования целевого кристалла ATMega16. Возможно, для надёжности следует уточнить коды команд интерфейса сериального программирования по даташиту целевого кристалла (хотя это вроде у всех АВР Атмелов однохренственно). В файле main.c надо задать счётчик возможных программирований и вставить код своего boot-загрузчика. Внимание! В приводимом исходнике main.c код загрузчика по понятным причинам искажён (потому работать и не будет) и приводится для наглядности. Код загрузчика (для тех кто в танке) берётся из Application Note AVR231.
Для того чтобы легко получить код своего загрузчика в виде исходного текста, я наваял програмку Hex2Src, которая принимает через командную строку имя файла загрузчика, например, boot.hex (можно не только в intel-hex формате, но и в motorola и tektronix). После запуска будет создан файл с тем же именем, но расширением .c. Из него надо взять нужное и с небольшими правками перенести в файл main.c. Думаю, трудностей возникнуть не должно.
После внесения всех правок компилируем проект BootProg. Поскольку в проекте используется eeprom, то выходной файл компилятора задан в simple формате. Так что для получения из него файла кода в hex-формате надо применить POSTLINK команду. Для простоты я её добавляю в оболочку IAR через "Configure Tools...". Надо ввести следующее:

Код

Menu Text: Postlink
Command: $TOOLKIT_DIR$\bin\POSTLINK.BAT
Argument: $TARGET_FNAME$ $TOOLKIT_DIR$\bin\POSTLINK.EXE
Initial Directory: $TARGET_DIR$

И поставить галку "Redirect to Output window". Сам файлик POSTLINK.BAT (оригинальный в директории BIN софта IAR) надо подменить на поправленный, который можно взять из темы тут.
После компиляции вызываем из меню "Tools" команду "Postlink". В результате получаем hex-файл прошивки ATMega48V. Зашиваем флеш, а зашивать eeprom нет необходимости - инициализация счётчика загрузок делается программно. Микропрограмматор готов!
---------------------------------------------------
Сделал я сей девайс и пришли другие идеи. Ведь такая штука может быть нужна не только для случая подобного моему. Например, вот ещё. Если увеличить память (другой контроллер взять), то можно шить не только загрузчик, но и вообще весь софт в целевой девайс. Тогда, допустим, это может быть востребовано на производстве - клепают девайсы и тут же шьют, ни компьютеров не надо, ни программаторов (надо только счётчик загрузок выкинуть). Один раз зашил где-то этот микропрограмматор, а потом только переливай.
Или вот ещё мысль. Можно сделать микропрограмматор (опять же если взять с большей памятью) на разные целевые кристаллы, - каждому своя "заливка". При этом, например, выбирать что заливать по коду кристалла, который считывается вначале. Или выбирать перемычками. Тогда будет "походный автономный заливатель" на несколько девайсов.

Прикрепленные файлы

 BootProg.rar ( 21.69 килобайт ) Кол-во скачиваний: 128
 Hex2Src.rar ( 39.33 килобайт ) Кол-во скачиваний: 99

 

[Dimonira]

Новости по результатам реализации нового варианта прошивальщика. Это когда шьётся не только загрузчик, но и сразу весь остальной код целевого девайса (либо весь код без загрузчика).
Отличие возникает в следующем (помимо того, что контроллер взял с большей памятью - ATMega168):
1. Прошиваемый код может иметь (и скорее всего) несколько кусков кода, которые никак не стыкуются своим началом и/или концом друг с другом в адресном пространстве флеш памяти, а могут и отстоять друг от друга всего на несколько байт, в т.ч. в пределах одной страницы флеш-памяти.
2. В основном коде может оказаться нечётное количество байтов. В загрузчике такого быть не могло, т.к. там только коды команд, а здесь могут быть, например, строковые константы.
3. Надо (скорее всего) прошивать ещё и EEPROM.
4. Шьётся boot-загрузчик + код, так что для загрузчика с контролем CRC надо, чтобы в итоге получилось правильное содержимое флеша, чтобы CRC при проверке была равна 0, иначе загрузчик не стартует основное приложение.

Сразу скажу, что последнюю проблему я решил просто - переделал boot-загрузчик, чтобы он не проверял CRC (в AES-загрузчике от Атмела такая возможность есть).
Для исправления отл.3, я добавил процедуру прошивки EEPROM в код прошивальщика.
Из-за отл.1 и 2, при засовывании в проект загрузчика вместе с основным кодом, прошивальщик работал неправильно. Первый кусок шился кроме последнего байта (из-за нечётности), а второй неправильно (из-за малого "отступа" от первого при наличии страничности).
Для исправления отл.2 я вставил в ispProgramFlash() загрузку байта 0xFF в последнее слово в случае, если оказывалось нечётное количество байт в массиве (любом) для прошивки флеша. Кстати, эта "ошибка" по-моему есть в коде всех доморощенных программаторов. Но их спасает, видимо, то, что Студия формирует массивы для прошивки нужным образом - с чётным количеством байт (при прошивке флеша).
А вот с отл.1 оказалось всё сложнее. Поскольку флеш прошивается странично, то пришлось учесть то, как разные непрерывные куски кода прошивки ложатся в память: начальные адреса, конец куска добить до целой страницы, но при этом учесть, чтобы он не залез на следующий кусок (у меня, например, получалось два куска, между которыми был всего один байт "пустоты") и т.д. Опять же Студия, по всей видимости, всё это учитывает сама и выдаёт по протоколу STK500 блоки данных с нужным выравниванием и размером (потому и моя реализация STK500 для программатора Dimoniprog работает). Но в этом случае ведь никакой Студии нет, шьётся всё автономно! Проблему пришлось решать. Я не стал исправлять код прошивальщика, а сделал так, чтобы массивы для прошивания уже были "как надо". Для этого модифицировал программу Hex2Src. Теперь она формирует массивы в исходниках выровненные на границу страницы и размером с целое количество страниц. "Лишние" байты вставлены кодом 0xFF. Взаимное положение кусков кода тоже учтено. Если при выравнивании куски "состыкуются", то они в итоге станут одним целым куском. При запуске программы Hex2Src теперь надо в командной строке перед именем файла (.hex) задать цифрами размер страницы флеш памяти целевого кристалла (не контроллера прошивальщика!), например:

Код

Hex2Src 128 mega16.hex

После такой подготовки массивов кодов для прошивки, решение проблемы с нечётным количеством байт стало неактуальным. Но я его оставил на всякий пожарный.
Поскольку теперь программа Hex2Src формирует выходные файлы сразу в "пригодном" виде, то я их стал добавлять в main.c директивой include. Только надо всё же поправить имена констант и массивов - я правил для boot-а (в boot.c) и eeprom-а (в eeprom.c), т.к. они скорее всего в процессе разработки не поменяются, а вот имена флеш массивов оставил как есть, так что при изменении прошиваемого кода просто перекидываю в проект загрузчика обновлённый файл code.c (название, понятно, условное) с новым кодом.
При наличии двух и более кусков, зашиваемых во флеш, надо добавить соответственно строчки (в main.c) с вызовами ispAddress() и ispProgramFlash() для этих кусков. Думаю это понятно.
Добавил зажигание светодиода на четверть секунды в начале при старте. Теперь ведь шьётся дольше, так что надо было как-то проинформировать, что "началось".
Ещё немного задержки увеличил на всякий пожарный. Лучше подольше, но наверняка.

Исходники нового "расширенного" BootProg и новой версии программы Hex2Src прилагаются. В исходняках, понятное дело, содержимое файлов boot.c, code.c удалено, оставлены начало и конец для наглядности. Файл eeprom.c секретности не несёт, так что его оставил как есть.

Прикрепленные файлы

 BootProg.rar ( 13.49 килобайт ) Кол-во скачиваний: 52
 Hex2Src.rar ( 39.99 килобайт ) Кол-во скачиваний: 48

 

[ReAl]

Кстати, эта "ошибка" по-моему есть в коде всех доморощенных программаторов.
...
Поскольку флеш прошивается странично, то пришлось учесть то, как разные непрерывные куски кода прошивки ложатся в память:

Обижаешь... Нет у меня такой ошибки
И байты - а пусть фрагменты (любое количество на странице) не только заканчиваются на нечётных байтах, а и начинаются на них, даже пусть хоть только одни нечётные байты в HEX-е прописаны.

[Dimonira]

Обижаешь... Нет у меня такой ошибки
И байты - а пусть фрагменты (любое количество на странице) не только заканчиваются на нечётных байтах, а и начинаются на них, даже пусть хоть только одни нечётные байты в HEX-е прописаны.

Имелась в виду embedded составляющая, которой у вас нет. Так что прошу не обижаться
Я уже писал где-то, что лучше AvReal софта не видел. Но теперь хочется от него поддержки STK500.