Вектора прерываний можно разместить как в области загрузчика, так и в начале памяти программ.
Есть программа загрузчик, есть основная программа, та и другая использует прерывания.
Но подпрограммы обслуживания прерывания разные для загрузчика своя для основной программы своя.

Так как таблица прерываний одна, а подпрограмм обработки прерываний две – одна относится к загрузчику, вторая к основной программе. Как это реализовать. И вообще если программа загрузчика и основная программа – разные программы и компилируются по разному, как быть с прерываниями непонятно, ведь таблицы прерываний будут определены два раза, а в памяти можно хранить только одну таблицу прерываний.

Делается очень просто ,
вспоминаете молодость ,когда не знали как тольком работать с прерываниями и делаете загрузчик без прерываний ,соответственно отдаете все прерывания основной программе.

Это заблуждение. Таблиц прерываний тоже 2.
Копайте в сторону IVSEL.

Вот из ДШ на M16

+1.
IMHO прерывания для загрузчика - лишнее, он должен быть простым и надежно писать флеш.


Кроме того у некторых AVR, например AT90CAN128, есть биты IVSEL и IVCE в MCUSR, которые позволяет иметь 2 таблицы векторов прерываний, в application и bootloader section соответствеенно. (и переключать их программно)

А кто сказал, что использование прерываний это сложно или ненадежно?!

При заливке программы нужно как то реализовать таймаут, чтоб вечно не ждать следующего байта, посчитать контрольную сумму, с программным переключением векторов надо попробовать, вроде то что надо, попал в загрузчик включил вектора в загрузчике, вышел, включил в программе. Думаю реализовать заливку бинариком, мне кажется проще, побайтно с $0000.

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

Выход ,если не дождались байта - это не проблема ,можно на стороне бута в цикле ожидания или по прерванию ,можно на стороне проги ПК, ждать пару сек ,если не пришло подтверждение приема или записи страницы (блока) данных ,ресетим МК соответственно опять входим в бутлоадер.Хотя вообще при нормально отлаженном бутлоадере и программе таких вещей не происходит.

"Шаманить" нужно будет в *.xcl файле. Но там всё достаточно просто.
А в самой программе перенос таблицы векторов - всего одна СИшная строчка. Использовать или не использовать прерывания в БутЛоадере - это вопрос из той же оперы, что и "использовать или не использовать прерывания в основной программе". Я лично в БутЛоадере ВСЕГДА использую прерывания.

Круто! Насколько я помню в режиме программирования FLASH-страницы должен быть запрещен WDT.
Это вероятно говорит о том, что процессор временно подвисает. Думаю, что во время программирования страницы ничего работать не будет вообще.

Источник не внушает доверия Даташит о должен быть запрещен умалчивает, а практика показывает что программирование flash и WDT прекрасно работают вместе.Неверная предпосылка, неверные выводы. Прочитайте даташит на предмет NRWW и RWW секций флеш-памяти.

Собственно WDT в бутлоадере особо делать нечего,хотя о вкусах не спорят.
Запрещать действительно прерывания нужно с момента записи в SPMCR и пока не будет выполнена SPM ,это касается всех прерываний.

В таком случае ,зачем тогда флаг SPMEN нужен ?И прерывание готовности SPM ,если в это время все равно ничего не выполняется?

Все верно, но если мы попали в бутлоадер с включенным WDT из основной программы по ошибке/или не по ошибке. Или напр, с установленным фузом WDTON..
WDT надо учитывать в бутлоадере.

Безоговорочно согласен!
Когда я писАл самый первый бутлоадер, то только с включеным WDT смог выловить неприятный, редко возможный, косяк.

А что, если установлен фуз WDTON, его действие можно запретить програмно?

Наоборот нельзя. Включен постоянно.

Из основной программы можно влететь и с включенными другими прерваниями ,переключить таблицу,и потом долго думать - шо за фигня твориться
А если не перенесем и начнем писать - вообще уйдем в аут.
Можно наставить не только WDTON но и BLB12,11,02,01 (они доступны и программно ) и долго догадываться почему у нас не читается\пишется и прерывания не выполняются.
Много чего можно наделать ,лиш бы желание было.




Я даже не сомневаюсь в том ,что для Вас использование WDT - это самый лучший способ отладки контроллеров.

Так уж категорично! Просто иногда включеный WDT позволяет поймать оччень неприятные гадости. Сработал WDT, программа остановилась в брекпоинте на старте, а дальше глядим эмулятором, что у нас творится с регистрами, стеками и т.д. Многое может проясниться.

Дело не в этом

Если Вы хотите что бы Ваше мнение не только читали ,но и пришлушивались к нему,стоит хоть как то аргументировать его,как это делает defunct или как Вы в последнем посте.
А на реплики ,я с таким же самым успехом могу отвечать репликами.

ЗЫ Здесь ничего личного,это Ваше право.

От этого есть лекарство - сразу при входе в бутлоадер запретить прерывания и переместить таблицу векторов в область бутлоадера, а в ней разместить заглушки "Reti" на все неиспользуемые прерывания...
Но это лекарство не всегда получается применить. Бывает банально нехватает пары десятков байт, и тогда в неиспользуемых векторах размещается код. В таких случаях на помощь приходит WDT. При входе в бутлоадер первым делом запрещаем все прерывания, провереям причину сброса (MCUSR) - если причина сброса не "WDR" то и ждем ~2cек (макс таймаут WDT) чтобы получить гарантированный сброс по WDT. После этого сброса мы опять в секции бутлоадера, но уже с отключенными всеми прерываниями и с причиной сброса в MCUSR - "WDR". И работаем в штатном режиме.


Ну уж
Биты защиты IMHO не надо приплетать сюда.
Если они зашиты, то стало быть так надо - кристал перешивать нельзя.

Бутлоадер нужно делать с особой тщательностью чтобы не было проколов в алгориме. Т.к. эти проколы (не учтенные прерывания, WDT и т.п.) могут привести к плачевным ситуациям - как например перетирание флеша бутлоадером "в поле" без видимых на то причин, в результате отказ, авария убытки.....

Ну допустим я сторонник входа в бутлоадер по ресету ,а не из программы,чесно сказать мне мало понятно зачем ей вообще туда лезть.Причины ,если будет интересно я назову.
Даже если ей и захотелось ,вот пускай и сама заботиться о том чтобы запретить все прерывания и собаку перед входом в бутлоадер,тем более что размера у нее куда больше чем в бутлоадере.
А если входить по ресету - все эти проблемы отпадают автоматически.
А если программа в бутлоадер случайно лезет из за своей кривизны,такую программу не жалко ,
тем более ей еще нужно красиво попасть именно в ту подпрограмму ,которая шьет ФЛЕШ,а защитить код бутлоадера от случайной порчи всегда можно установкой соответствующих фузов и естественно сохранить загрузку работоспособной и иметь возможность сделать перезагрузку.

Представте себе ситуацию. У Вас N устройств на луче RS-485. Все они выполняют свою работу. Теперь программист говорит - "Ааа!!! я нашел косяк и ПО нужно обновить"! Как это сделать? Один вариант: придти с ЛапТопом плюс программатор и перешить нужные девайсы. Попробуйте поскакать на стремянке, где устройство находится на высоте метров эдак 5 от пола и устройств порядка 80-ти. Я так думаю, энтузиазма эти телодвижения у Вас вызовут мало.

Что было сделано. В основную программу добавлен небольшой фрагмент, который переводит устройсво в БутЛоадер. При инициализации БутЛоадера сразу переключаются вектора прерываний, понятно куда. Обновляем ПО и по окончании процесса командой JMP 0x0000 передаем управление основной программе. И эти телодвижения делаются из, например, центрального поста, пультовой, или как там это ещё можно назвать. Т.е. со стремянкой бегать не нужно, потому, что обновление ПО делается из одного места в комфортных условиях.
Убедил?

кроме названной Игорем, может быть еще:
- Непредвиденный прыжек в область бутлоадера в результате глюка программы, либо в результате просадки питания с летальным исходом для содержимого внешнего RAM'а.

РАЗ. Попадаем в Лоадер, ДВА-глядим, а какая "сволочь" нас туда вогнала? Если это намеренно(команда по одному из интерфейсов), то делаем то, что нам скажут. Нет? А если нет(команд не последовало) то ждем чуток и вывыаливаемся,например по WDT, из лоадера и передаем управление основной программе.

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

Конечно можно.

Нет не убедили .Хотя как вариант он имеет право на жизнь.

Давайте опять вспомним молодость ,когда впервые нам удалось вывести свой первый символ на экран ЖКИ,потом перепрошивка для вывода уже строки с оставленным включенным и инициализированным ЖКИ ,ввели строку ,выключили питание ,включили ... и болт Круглые глаза какого не пашет ,ведь только что работало Потом спустя час догадываемся что накосячили с инициализацией или таймингами пока переделывали программу
Я привел самый простой и безобидный пример с которым сталкивались если не каждый то многие.Тоесть к чему может привести перепрошивка МК в уже инициализированной системе.

Поэтому нужно предусмотреть не только вызов конкретного МК для перепрошивки ,а также чтобы остальые МК заткнулись на шине и не мешали ,также после перепрошивки дать всем знать чтобы могли продолжить работу ,кроме того в программе перепрошиваемого МК неоходимо предусмотреть корректный вход в уже инициализированную систему.
Не слишком ли много головной боли ?
Я уже не говорю ,что можно просто накосячить в проге и посадить всю сеть ,тогда уж точно без стремянки не обойтись

Поэтому для меня переход по ресету остается наиболее надежным способом входа в бут.И к томуже
он вполне подходит и для прошивки нескольких МК на шине.
У меня нет 50устройств ,я прошивал Мегу8 и мегу88 на одной шине ,чисто ради интереса - без проблем .
Способ работы своих бутов я уже описывал.

1Включаем питание и ждем 2 сек команду соединения,если нет переходим на выполнение программы.

2 Если есть - все МК входят в бут и ждут команды.(для разных МК разные комманды ,но есть две одинаковые "IN" и "OUT"),если например одинаковые МК можно придумать свой ID,сам принцип я думаю понятен.

3 Шьем,читаем и д.т.,на выбор

4 "OUT" - одновременно все выходим и стартуем.

Все Просто и надежно,при этом можем иметь свой независимый протокол и скорость чисто для перепрошивки.



Глюк программы - не в счет,тем более я напоминал ,что ей еще нужно угадать ,так как просто вход в секцию ничего недаст.

Насчет просадки питания ,незнаю как у Вас ,но у меня при просадке МК входил в такой ступор ,что я его не мог вывести даже внешним ресетом ,не то что протоколом или собакой.
Меня даже не это расстраивает ,а то что сносит ЕЕПРОМ при этом.
Поэтому в данной ситуации мне помог только BOD ,если раньше сносило целые блоки ,то сейчас очень редко первых пару байт ,решил проще ,занес базовые настройки во ФЛЕШ ,а пользовательские оставил в ЕЕПРОМ.Перейду на ULP серию - возможно мне полегчает

Очень даже в счет. Представьте, есть некий контроллер электроподстанции 35KV, что-то глюкануло (на подстанциях всяко бывает), и вместо перезагрузки, у контроллера вдруг сотрется флеш. Считайте город остался без света на пару дней (если есть запасной контроллер, тогда на пару часов). Не будь там бутлоадера флеш бы не стерся, программа бы перезапустилась по WDT и все бы работало дальше. Выходит бутлоадер виноват, и ведь так и есть, кто как не бутлоадер флеш стер?..

Полезного - ничего, а вредного запросто, по самые "нехочу".
Затрется пара страниц флеша, и ищи потом причину месяцами..


Я говорю не про MK, который кстати может свободно перенести скачек питания 5->1.8->5. А про внешний RAM, который 5->1.8->5 однозначно не перенесет.

Ну от этого ни кто не застрахован! Перед тем, как дать прошивку "прошивальщику", лично я пару дней "погоняю" новую версию программы на стенде, на предмет "самовозгорания"(с), и если всё в порядке, то тогда даю отмашку - "Шей! Вся ответственность на мне". Забыл как выглядит стремянка.

В принципе все верно и можно согласиться,но вы упустили пару моментов.

1 чем отличасеться глюк программы с бутлоадером по протоколу и с бутлоадером по ресету ?
Такой же самый может глюк произойти- не вижу разницы.
2 Бут по ресету ,так же само как и бут по протоколу нуждается в протоколе
,таже команда входа,таже команда записи,поступление данных и только после этого запись.

Даже если вести разговор про какие то вероятные глюки ,то вероятность входа в бутлоадер программы переходящей по протоколу выше ,чем чем переход в бут по ресету,так как команда перехода опрашиваеться только первых пару секунд ,а у протокольного перехода должна опрашиваться постоянно.