Решил прикрутить к своему девайсу самопрограммирование через RS232...
(RS232 уже реализован rx, tx, dsr)

Кто плавал подскажите как со стороны МК это более грамотно реализовать...
(Доки Атмела читал, но по данному вопросу другой информации не нашёл)

Какие грабли ждать?

Какой протокол (если есть готовый) использовать?
(или самому насочинять...)

Куда сместиться таблица прерываний?
(понимаю, что в зависимости от настройки фусов,
но када, сразу после бут области?)

По мимо всего прочего интересует вопрос сброса... ну предположим
по определённой команде программа перейдёт в бут область...
Как вариант - прерывания у меня отключены на время прогрева,
настройки бортовой (на МК) периферии и тестирования ОЗУ...
После этого проверить пришел какой либо заданный символ за это
время по рс 232? Если да - самопрограммирование... но вопрос
как реализовать после всего этого Софтовый резет?

Немного истории:

Когда я разрабатывал Book reader на AVR ATMega16
http://www.swordgreenline.narod.ru/BookReader.html
столкнулся с проблемой занятости SPI порта программатором.

Залил прошивку, вытащил программатор, воткнул в этот разъём ММС флэш,
перезапустил устройство, подтвердил вход (иначе был риск управлять
вместо флэши программатором), проверил нашёл ошибки (скорректировал
исходник), выключил устройство, вынул флэшку, воткнул программатор
и т.д. муторно и долго...

Теперь хочу сделать девайс на Mega32 с периферией:
SPI MMC флэш
RS232
LPT(мастер) на основной плате для подключения "стандартной" комповой периферии.
и 4х битная шина дисплея с МК опроса АТ клавиатуры на
вспомогательной...

и что бы
1) ускорить прошивку девайса (через LPT очень медленно)
2) не заниматься передёргиванием то флэши, то программатора в один SPI
хотелось бы прикрутить самопрограммирование...

Делаю так.
После сброса попадаем в область загрузчика (для чего программирую соответствующий FUSE).
Затем перемещаю таблицу векторов в область загрузчика.
Затем делаю тест целостности программы.
Если она повреждена записываю это в последнюю страницу FLASH и жду загрузочных пакетов. При этом отвечая на "вопросы" внешних устройств о моём состоянии "Мой софт разрушен. Жду загрузки софта. Софт загружен до ... -ого блока".
Внешнее устройство, которое будет передавать мне прошивку получив мой пакет начинает передавать мне прошивку блоками начиная с того пакета, который я указал.
В самом первом блоке FLASH храню номер версии прошивки.
А при передаче пакетов с программой я всегда указываю в пакете к какой версии софта относиться данная прошивка (поскольку в сети одновременно могут обновляться прошивки нескольких разных устройств)

Уф.. Пока хватит.. Хотя я не перечислил и 10-й части всех нюансов и тонкостей организации работы загрузчика...Итак много букв написал.. Если есть неясные моменты и более конкретные вопросы - задавайте

если можно немного подробнее с этого места....
я ещё не совсем понял как разрулить прерывания...
ну предположим (хотя не обязательно) загрузчик будет пользоваться прерыванием рс232
но относительные адреса прерываний от версии прошивки к версии будут плавать?
(т.к. указывают на изменяемые во время перепрошивки блоки)

как реализовать выход из прошивки (без внешнего сброса)
если использовать внешний вход в эту область - это может быть не надёжным,
т.е. надо как то определиться при старте с перепрошивкой...

изобретать систему команд званого, или есть готовые или хотябы описание их набора?
(я про CRC16 и проверки)
Планирую использовать алгоритм CRC16 от флэшки MMC раз он у меня уже написан...

Вектора прерываний в загрузчике должны указывать на обработчики, находящиеся в загрузчике. А под загрузчик я всегда использую всю секцию NRWW флэши.

А эти обработчики могут либо всегда сами обрабатывать прерывания(т.е. они не будут меняться от прошивки к прошивке). Либо можно грузить адрес перехода из ОЗУ. Либо в загружаемой программе можно сделать свою таблицу векторов которая будет использована после окончания загрузки и переключения на таблицу, расположенную в RWW.


Я сначала проверяю целостность прошивки. Затем смотрю содержимое служебной области FLASH или EEPROM(не поступали ли команды извне на перезаливку софта). И по результатам перехожу либо на сброс в RWW(т.е. передаю управление приложению) либо перехожу в режим загрузчика.

Перезагружаться из программы то как?
Прыгнуть на начало? Заново залить указатель стека и забыть о том что
находишься в какой то вложенности? или как?

Ps to All
вопросы по программированию протокола не снимаются
изобретать всё заново и вслепую искать грабли (наступая на них)
или кто уже делал?

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



((void (*)())0x0000)();
только если пользовались IVSEL не забываем его перенастроить на App область

Для начала посмотрите AVR-109.pdf и AVR-109.zip, все довольно просто и работает со стандартным АВРПрогом.

Спасибо конечно, но:
1) Я это уже читал.
2) Работаю я на асме
3) Хотелось бы без переделки аппаратной части... (нет свободных пинов)
4) причём пунк 3 не основной, в идеале хочу получить нажал мышкой - прошивка залилась...
(а тут надо думать о резете и замыкать пин...) на рс232 это не вешать библиотека на хардовый
режим настроена





Я к сожалению не знаю всех тонкостей работы с фусами...
На данный момент запускаю фусы так
http://palmavr.sourceforge.net/cgi-bin/fc....amp;B_BOOTSZ0=P

проще спрошу что надо выставить и куда при этом уйдут вектора прерываний...
(на данный момент мне было бы удобнее что бы вектора прерываний шли сразу после бут области
и переписывались каждый раз...)

И смежный с этим вопрос как пояснить студии что в коде появилась бут область
(я пишу в блокноте, компилирую батником и иногда отлаживаю на студии)

Я делал по Watchdog-таймеру... Правда не в AVR32, а в ATmega-х. Также перезагрузку каждую минуту делал если девайс находился в режиме загрузчика, а пакеты загрузки не приходили



Ну это уже другая тема к загрузчику НИКАК не относящаяся, поскольку протокол приёма/передачи пакетов не зависит загрузчик у Вас или не загрузчик - что в пакет положите, то и передадите. Создайте отдельную тему "Реализация стека протоколов"


Положение таблицы векторов задаётся не ФУСАМИ, а программированием соответствующего регистра статуса и управления.. Курите даташифт



Надо просто задать с помощью директивы .ORG положение кода загрузчика.

А при прогоне проги в симуляторе, чтобы у Вас прога стартовала в NRWW надо поставить галку Debug/Simulator Option/Enable Boot Reset

Передавайте в пакете строку Hex-файла, ну а для ответа достаточно одного байта -
продолжить / повторить / продолжить с задержкой (жгу страницу) / закончил

Слишком большая избыточность кодирования. Коэффициент аж 2. Скорость заливки будет низкая. Лучше в бинарном формате передавать, а не в ASCII

Доктор, Вы как крупный специалист в области протоколов, какой протокол посоветуете?

А Вы не согласны, что передавать в ASCII слишком накладно, т.к. скорость заливки упадёт в 2 раза..А?

Вы можете посоветовать протокол или не можете? Не можете - так и скажите.
А на попытку начать флуд я не ведусь.

Аналогично. Тоже не ведусь на Ваши попытки. Засим дискуссию с Вами я прекращаю.

Я согласен...
А исходя из того что писать за раз меньше или больше одной страницы нельзя то предагаю буфер размером со страницу... потом 2 байта CRC16...

команда залить в буфер страницу и принять байты и срс
команда считать буфер в рс232 и срс
команда задать адрес страницы
команда читать страницу в буфер
команда писать из буфера в память
команда софтовый сброс (только так и не понял пока как)



Заранее на 100% предугадываемый вопрос...
А какие регистры статуса за это отвечают?
(Плиз. датащит большой и поиск почемуто неработает...)

см. IVSEL.




У меня используются такие команды:
1. Запись страницы (передаются зашифрованные данные)
2. Чтение страницы (передаются зашифрованные данные, шифрование совпадает с командой "запись")

(т.о. расшифрованные данные будут только внутри МК).

3. Проверка целостности (проверяет не блоки, а CRC всей пользовательской секции, плюс выдает последнюю страницу пользовательской флеш "как есть" (т.е. не шифрует ее), в этой странице хранится версия, дата создания, и проч. информация о залитой прошивке, защищенная отдельной CRC).
4. Выход из загрузчика (делается JMP 0x00, предварительно выключив всю периферию которую использовал бутлоадер).

Протокол modbus RTU.

Посмотрите по этой ссылке.
http://www.fractal.com.ru/_pdf/description/4_39.pdf
это сделано для pic18 контроллеров, но легко может быть реализовано для AVR

Долго искал на асме и под авр
и вроде откапал... Нажмите для просмотра прикрепленного файла
система команд вроде "стандартна" только пока не разобрался
"стандартна" для чего?

сейчас ковыряю hex формат....
вроде пока ковыряется...
прошивкой займусь позже...

если кому интерестно рад буду обсудить...

А зачем?

Да трудно с вами...
А чем шить результат то по твоему?

У меня собственная терминалка с макросами...
(под каждую задачу свой набор команд отправляемых по таймеру)

Почему?


Что такое "результат"? И почему его надо "шить"? Насколько я знаю "шьётся" в микроконтроллере FLASH или EEPROM


И какое это отношение имеет к Вашей фразе "сейчас ковыряю hex формат"?
Не обижайтесь. Я правда не улавливаю связи.. Простите

Если хочешь, пришлю готовый проект под IAR С mega 16/32/64/162/128 при одном условии - не выкладывать.

Почитайте тут
http://avrubd.googlepages.com/avrub.htm
про универсальный загрузчик...

Условие не выкладывать я соблюдаю всегда...
(у меня ни одного исходника на сайте)

Но мне бы под асм...
если не трудно опиши алгоритм в 2х словах...
как я понял у мег 16/32/64/162/128 размер страницы одинаков?

На ASM будет более запутано.
Да и собсно какая разница под что, если вам только посмотреть?


разный.
8k флеша - 64 байта страница
16k/32k - 128 байт страница
64k/128k - 256 байт страница.

Всем спасибо пока всё боле или менее прояснилось буду стыковать ПК с железом...
Если есть примеры Я ЗА !!!