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

Сообщение отредактировал namelos - Sep 25 2007, 13:31

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

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

Сообщение отредактировал namelos - Sep 25 2007, 13:31

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.

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