Из основной программы можно влететь и с включенными другими прерваниями ,переключить таблицу,и потом долго думать - шо за фигня твориться
А если не перенесем и начнем писать - вообще уйдем в аут.
Можно наставить не только 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 Бут по ресету ,так же само как и бут по протоколу нуждается в протоколе
,таже команда входа,таже команда записи,поступление данных и только после этого запись.

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