Доброе время суток, господа эмбеддеры.
Написал программу в AVRStudio-WinAVR 20070525(avr gcc 4.1.2) . В целях защиты хотелось бы заполнить сводное место Flash-памяти "rjmp 0" и посчитать CRC всего кода программы для проверки целостности. Подскажите пожалуйста, как мне это реализовать. Если можно поподробнее. Заранее спасибо.

А в чем защита если заполнить всю память джампами? А вот грузиться при перепрошивке код будет реально дольше.

Использование джампов параллельно WDT, полагаю, снизит вероятность подвисания контроллера. Или Вы думаете, уважаемый GDI, что только WDT уже достаточно?

2 namelos - а что для вас означают слова - "..подвисание контроллера.."?

Не снизит оно ровным счетом ничего.
Заполнять свободное пространство джампами нет смысла, потому что опкод FFFF, которым заполнен флеш, к зацикливанию не может привести, а следовательно PC самостоятельно выйдет на адрес 0.
Проверку целостности должна выполнять программа-компаньен (загрузчик) размещенная в boot секции, и реагировать на сбой флеша соответвенно - давать возможность перезашить чип.
Но в подавляющем большинстве случаев - достаточно только WDT.

Уважаемый defunct,
Сразу появляется вопрос, как организовать проверку целостности? Что проверять, всю программную часть или только часть?
По вашим суждениям я понял, что заполнение свободной памяти не имеет смысла, но к сожалению не услышал как это сделать. Как я предствляю, заполнить память возможно только изменением hex-файла с дописанием бинерной команды rjmp 0. Есть ли способ попроще?

2 Kuzmi4, под "подвисанием" контроллера- понимаю зацикленную работу контроллера, например при получении в PC aдреса сводного байта памяти с неизвестным содержанием.

В приведённом вами примере собачка - идеальный вариант...

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

Какова гарантия ,что не слетят начальные адресса кода ? ,не поможет ни собака ни джампер.
Вообще у меня флеша как правило слетала полностью.

Забивать НЕХ запаритесь ,rjmp - это команда относительного перехода ,тоесть каждая последующий адресс перехода в ней на 1 больше,если охота попасть в одну и туже точку.
Вообще такие проблемы решаются как правило ваянием простенькой утилитки на компе в течении 30-60 минут

У меня проверяется вся секция основной программы.
Как это делается -
Есть программа упаковщик (на PC), и программа bootloader распаковщик в MK.
упаковщик открывает Hex файл, добавляет к нему одну страничку флеш со служебной информацией (дата/время создания, код железа для которого предназначена прошивка, версия, название, CRC и т.п.), шифрует все это дело. В МК зашивается bootloader, лочится секция бутлоадера и основной программы. Потом запакованный ранее файл шьется в МК уже средствами бутлоадера (расшифровывается внутри МК). Bootloader при старте МК провереяет CRC секции основной программы, с CRC записанной в служебной страничке флеш. Если совпадает - передает управление на адрес 0, если не совпадает - включает красный светодиод (если есть) и ждет команд сверху.


перепаковать Hex в Bin, добавить требуемую информацию, и перепаковать Bin обратно в Hex.


Если только добавить заполнитель, то возможно есть соответвующая опция линкера, но я этим особо не интересовался.

Надо бы не

а

Тогда собачка сделает сброс по таймауту, и это будет настоящий(правильный) сброс.

Да зачем это делать то? Стертая флешь имеет вполне определенное значение в ячейках, как уже упоминалось 0xFFFF - это команда SBRS R31,7, если программа каким то образом попадет на незашитую область, то просто дойдет до конца памяти программ и попадет на нулевой адрес, если раньше не сработает собака и все не перезагрузит. Зачем изобретать велосипед и бороться с несуществующими проблемами? Другое дело что после подобной перезагрузки(что собакой, что джампом) в ОЗУ будут какие то значения, которые там были на момент сбоя и как это повлияет на дальнейшую работу программы не известно, на и отсюда есть выход - инициализировать переменные перед использованием.

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

У меня не инициализировались при включении/RESETe регистровые пары X и Y, пока не написал обнуление вручную - "многа думаль". Это было на 90S8515.

Достаточно заглянуть в даташит - там нигде не сказано, что регистры ядра обнуляются при ресете или включении питания. Для регистров периферии такая информация есть, для ядра и ОЗУ - естественно нет, ибо зачем их обнулять аппаратно?

Разобрался с Intel-hex файловым форматом, но в конце каждой строки hex файла стоят 2 байта 0D 0A, значение которых пока непонятно. Или они просто заканчивают строку?

0d 0a = \r\n - это перевод строки

GDI, спасибо.

Чтобы проц поменьше слетал , очень важно !!! сделать правильную разводку питания на проц.
Как показывает опыт , при правильной разводке питания может даже не потребоваться собака ( если конечно же речь не идёт о сверхмощьных ЭМ помехах вблизи ) . Это первое .
Если хочется побольше надёжность , - совет - не жмитесь и ставьте внешний тактовый генератор . В крайнем случае , если такой возможности нет , то включите у проца бит максимальной амплитуды тактового сигнала . Но внешний генератор вне конкуренции .
Не жмитесь на фильтрацию по питанию .
Очень непомешает внешний супервизор с отличным от Brown-out проца значением . Т.е. например Brown-out проца заводишь на 4 вольта , а внешний применяешь со значением 4,5 вольта ( например MCP-450 производства Microchip ).
Если внешний сброс не применяешь , то через 1 килоом вывод сброса на питание проца , и его же через 0,1 микрофарата об землю.
Собаку я включал последний раз лет 5 назад . При тысячах едениц выпущенной продукции вроде бы нареканий нет.
Что касается rjmp 0 , то как правильно уже было замечено , должно быть jmp 0 , но смысл в этом нулевой .
При старте можно сделать проверку CRC кода (ATMEL в одном из app. показывает как это сделать ) , и если битая память , то заставить девайс перепрошить .
Если всё это делаешь , то забываешь о rjmp 0 и о jmp 0
Удачи

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

Ни то , ни другое . Что касается программ , то по обьёму кода программы конечно же разные , но как правило не менее 30-40К памяти программ ( все программы пишу на асме ) Так что не очень они маленькие , я вас уверяю . И проц шуршит аж воротник заворачивается - прерывание на прерывании . И пожалуйста только не надо приводить старые как мир догмы - писали бы на Си . . . Я и на Си могу , но для меня асм комфортнее .
Гением конечно же себя не считаю , и ошибки бывают , кто не грешен ?
WDT не защищает от помех, WDT может защитить от программных ошибок - зацикливания, тупиковых состояний КА и т.п.

Это что же получается - производители вводят в проц апаратные вещи для защиты от кривых программистов ? Неожиданная мысль , очень неожиданная .
На самом деле это не совсем так . Вы не задумывались почему некоторые процы (рядовые) ( например MSC-51) работают на 50 MHz , а у AVRов пока планка в 20-24 MHz ? Дело в том , что у AVRов выборка команды производится за 1 такт генератора , но за 4 внутренних такта , которые формируются специальной внутренней аппаратной схемой .Так вот - сбой хотя бы по одному из этих подтактов приводит к разным непредсказуемым последствиям (и подвисаниям в том числе ) . Именно поэтому важна хорошая форма тактовых импульсов , так как на основании её формируются внутренние подтакты . Некоторые производители ( NEC например) применяют для защиты от такого рода вещей специальный аппаратный механизм правильной выборки команды из памяти программ. Именно для подобных вещей держат псов , а не для защиты от программистов !!! .
Небольшое лирическое отступление-: когда - то давно , когда я ещё был студентом , нас то и дело доставал препод по программированию составлением алгоритмов . Всех это уж очень достало , и я один раз в сердцах спросил - когда же вместо вской ерунды мы начнём изучать языки программирования ?.
На что получил ответ , который оценил позднее - язык программирования это инструмент , а программа - это исскусство и часть души . В корявых руках и скрипка Страдивари будет не более чем куском дерева .
Умный был ( надеюсь ещё есть ) препод .

Лет 10 назад делал одну програмку . Писал , она работала , дописывал , она опять работала , пока в один момент всё не стало работать очень коряво . . . ( справедливости ради надо сказать что у неё была очень сложная структура ) . Разбираться в огромном куске кода небыло никакого желания - крышу срывало.
Было принято волевое решение - взять и разрисовать прогу на блоки , сначала крупные , потом помельче , потом ещё мельче . В итоге ( после месяца спания по 4-5 часов за ночь ) - получилась структурная схема программы. Она была очень тщательно осмыслена и проверена на логику работы .
Меня тогда удивило - по структурной схеме мне только и оставалось что просто тупо подставлять ассемблерные операторы , что у меня получалось очень и очень быстро ( за неделю одолел 32К ). Кстати , предыдущий кусок весил 36К .
Первое включение после компиляции и прошивки и . . . . . каково же было моё удивление , что программа заработала сразу , и без малейших шороховатостей . Я после включения не изменил в программе ни одной буквы , так до сих пор и работает . После этого случая я любую программу пишу именно так - сначала хорошо обдумываю всю структуру программы , тратя на это прилично времени , затем начинаю на бумаге делать наброски , потом всё чётче и чётче вырисовывается программа , нечто наподобе проявки фотографии , или прорисовки художника. Совет - хотите писать хорошие программы - делайте именно так - я вас уверяю - времени в итоге тратится меньше , сохраняется "бумажная копия" работы программы ( в которой может разобраться при необходимости практически любой грамотный человек , даже далёкий от программирования ). А ошибки ищются на ура . И никакой язык программирования не сравнится по наглядности ( Си в том числе ) . . . Поэтому лично для меня какие из операторов подставить в программу - асм или Си особого значения не имеет .
От кривых рук программиста не спасёт ни собака , ни другие аппаратные вещи .

Подтверждаю. Из своего немалого опыта программирования для PC вынес (правда, не сразу) эту же мысль - чем больше времени потратишь на тщательное продумывание программы (прежде чем прикасаться к клавиатуре), тем меньше общее время "продумывание+написание+отладка+доведение_до_ума".

Вставлю-ка я свои 5 копеек:
Как уже упоминалось ранее, значение 0xFFFF - это код команды SBRS R31, 7. Но никто почему-то не обратил внимания на то, что при R31.7=1 процессор может и не выйти на нулевой адрес. Так что заполнение имеет некоторый смысл (по крайней мере, заполнение последнего слова памяти).

SBRS - Skip if Bit in Register is Set
16-bit Opcode: 1111_111r_rrrr_0bbb

Соответственно, опкод SBRS R31, 7 = 0xFFF7.
Среди документированных я не нашёл инструкцию с опкодом 0xFFFF.
Интересно, что делает контроллер, встретив такую инструкцию, пропускает?

AVR Studio декодирует так. Можно эмулятором проверить для надежности.

Вот дизасемблер АВРстудии:
+00000008: CFFA RJMP PC-0x0005 Relative jump
+00000009: FFFF ??? Data or unknown opcode
+0000000A: 0000 NOP No operation
+0000000B: FFFF ??? Data or unknown opcode

"...эмулятором проверить для надежности." - это шутка?
Эмулятор даже документированные фичи не все отрабатывает.

Я это узнал из дизасма IARа, а разработчики этого компилятора учавствуют в разработке опкодов команд для АВР. Правда это был дизасм кода из еепром, ну не встречается у меня в программе такого опкода...

В процессе отладки с JTAG-ICE на ATmega128 сам наблюдал как попадая на незапрограммированную область процессор доходит до конца флэша и начинает выполнение программы с начала.

Watchdog за многие годы спасал один раз и отнюдь не от программых ошибок - индустриальные PCшки попалась и ушла на объекты партия с какими-то дивными сбоями при работе DMA контроллера Ethernet - сносило крышу начисто. Watchdog чуть-чуть-чуть смягчил проблему до того, как через пару дней были приняты меры по обкладыванию работы с Ethernet подушками для обхода дефекта и последующей замены железа на рабочее. В принципе до этого эффекта Watchdog в этом софте размером порядка 300K даже не активировался. Давить программные ошибки Watchdog-ом чистый моветон

Есть у меня одна неразрешенная загадка: в одной программе на MEGA8, интенсивно использующей инструкции Ldd/Std, иногда наблюдались ошибки на границах страницы ОЗУ 0x00..0x100. Это может быть тоже гонка фронтов?

А на счет заполнения- NOP - и вся любовь
Затем, после rjmp Start, обязательно, CLI и инициализация всего, чего надо, как будто
мы не знаем ничего о начальных значениях портов. Теперь у нас "взбрык" от сброса внешне ничем не отличается.

В который раз повторяю: нежелательно вешать на ресет ёмкости! Почему? А обьясните мне что будет при пропадании питания?

Тогда без эмулятора, руками - делов то.
Старая студия (3.56) в дизассемблере выдает тоже SBRS R31, 7.

Cработает BOD-если он включен и правильно настроен порог,т.е ничего страшного не будет.

2 WHALE - не совсем. я так подозверваю что Petka имел ввиду чт оесли уровень на ресете будет падать медленнее чем на питании МК , то мы потом поимеем геморрой...

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

Это откуда же такое тайное знание? Вы видели исходник?

Вы имеете в виду, выход на адрес 0x0001 вместо 0x0000. Да действительно возможно, но не проще ли будет по адресу 0x0001 поставить JMP туда же куда делается в инструкции по адресу 0x0000. Тем более вы упускаете тот факт, что процессор может прыгнуть в несуществующую область памяти, при чтении которой возвращается тот же 0xFFFF, вероятность прыжка в несуществующую область памяти прямопропорциональна количеству оной, например для M16 вероятность прыжка в несуществующую область памяти = (128 - 16)/128 = 7/8 = 0.875


Позволю себе несогласиться с вашим выводом.
Про моветон можете говорить в форуме по АРМ, у которого имеется возможность обработать или "задампить" крашевую ситуацию (DABT/PABT/UNDF). У AVR'ра нет обработчиков исключений и в промышленных изделиях только WDT может подстраховать в случае серьезного программного сбоя. WDT в AVR можно рассматривать как обработчик исключений. Считаю, что конечный продукт на AVR с отключенным WDT - дилетанство, такое же как если в изделии оставить чип в отладочном режиме (фуз OCDEN).

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

Тогда вы возможно не так поняли мой первый пост.
Никто никогда не застрахован от программных ошибок, которые часто проявляются в полевых условиях, а не на стадии цикла тестирования. В ARM с отловом таких ошибок проще - по факту abort'a, сразу есть и место ошибки и стек (в AVR только по WDT). Отлаживать и устранять приходится по дампу памяти снятому в полевых условиях - такой процесс иногда затягивается на месяцы, и пока проблема устраняется, WDT скрывает проблему от потребителя (системе ж надо как-то работать), но он ни в коем случае не скрывает проблему от разработчика.

Допустим, для MEGA16 PC "13-bit wide", как пишут на несравненном атмеле.
Я так понимаю: старшие биты уже в нулях. Далее, пусть глюк пошел по адресной шине.
Ну и что - будет не 0xFFFF, а выборка случайной команды по модулю 2^16 или 2^13, т.е. конкретный глюк.
Таким образом, в прямую пропорциональность вероятности прыжка... не верю

Обьясняю :
Если вы рассмотрите структуру порта , то увидите что каждый порт защищён защитными диодами , причём один диод на землю анодом ( защита от отрицательных напряжений ) , другой диод катодом об питание процессора . Так вот при выключении питания верхний диод будет смещён в прямом направлении и разрядит ёмкость на питание . . . Непойму в чём проблема ? Неужели это надо обьяснять ?

точно. упустил.

да ее нет. Но предложение добавить команду перехода по адресу 0x0001 остается в силе, тем более для МК с >=16k флеш, это можно сделать не жертвуя вектором INT0.

Проблема в том, что на сбросе этого диода НЕТ.

Достаточно хотя бы посмотреть в документации на любой AVR тактирование ALU , и попытаться разобраться как вообще происходит работа за 1 такт . MSC-51 делили такты на 12 от нечего делать ? Сейчас MSC-51 как правило делят на 4 , или поступают аналогично AVR.
Если верите больше своим глазам , то можите поставить эксперимент :
берёте AVR , запускаете на 16 MHz например . Затем вместо 16 MHz запаивает например 27 MHz ( можно найти кристаллы , которые запустятся на этой частоте ) . Так вот работать они будут медленнее чем на 16 MHz . Почему надеюсь обьяснять ненадо ?


Да , ошибся , извиняюсь . Так а кто его мешает поставить ? ( желательно Шоттки )

Думаю надо. Загадки это хорошо, но коль скоро вы подняли тактовую до 27Mhz и оно у вас как-то работает, (fully static логика) работать должно быстрее либо вообще никак.

А как быть с другими зверьками помельче? ИМХО, только заполняя нулями неиспользованные ячейки.

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

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

Только к ним еще резюк надо (как правило они с открытым стоком/коллектором) , а так действительно тот же MAX809 в SOT23 и резюк займут меньше места.

Если внимательно перечитаете что мной написано , то увидите что там как раз и предлагался преимущественно супервизор ( и даже назван какой например ( MCP-130 - 450 ), и написано что в случае . . . бедности применять "резистор + конденсатор + диод +. . ." .
И никто и не спорил что интегральный супервизор на голову выше "резистор + конденсатор + диод +. . ." Но супервизору и самому нужна блокировочная ёмкость по питанию. А подтягивающий резюк уже встроен в этот супервизор .
Моя фраза "Если внешний сброс не применяешь" задумывалась как "Если внешний супервизор не применяешь" , что возможно и вызвало некоторое недопонимание . Т.е под сбросом в данном случае подразумевался супервизор , а не пин проца .

Такого вы не предлагали, это раз. Схему с конденсатором и диодом я не рекомендую использовать даже в "случае бедности" т.к. и в этом случае надёжность будет только хуже чем просто резистор 1-10кОм на питание.