[Don_Ambrosio 0]

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

 

Приведу пример

--------------------

lab_1_input: ldi R16 , $00

mov R16 , $98

...

lab_1_output: mov R17 , R5

-----------------------

lab_2_1_input: mov R18, R17

 

 

Т.е. допустим программа предусматривает переход к выполнению кодового фрагмента, начинающегося с метки lab_2_1_input только после отработки до конца фрагмента [lab_1_input;lab_1_output]

 

А представим , что от помехи произошёл случайный переход из произвольной точки 1-го фрагмента кода в произвольную точку 2-го фрагмента кода....

 

Как вы ПРОГРАММНО отлавливаете такие ситуации?

 

Т.е. как Вы реализовываете в своих программах для микроконтроллеров ATmega механизм защиты FLASH-памяти от несанкционированного выполнения кода. Ну т.е. как контролировать, что в данный фрагмент кода вошли не где попало, а через строго определённые на этапе проектирования программы, точки

 

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

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

Может также случайным образом измениться содержимое ячейки FLASH или содержимое хранимой в ОЗУ таблицы переходов... В любом случае МОЖЕТ произойти переход в точку некоторого логического сегмента кода, которая не предусмотрена данным логическим сегментом FLASH

[Liseev 0]

А как вы будете защищать "механизм защиты от несанкционированного выполнения"?

А механизм защиты механизма защиты?

А от прямого попадания молнии? :)

 

Используйте WDT от "случайных" зависаний ну и, пожалуй, проверяйте CRC программного кода.

Здесь эта тема броде бы обсуждалась

[Don_Ambrosio 0]

Используйте WDT от "случайных" зависаний

ИМХО, "случайные зависания" в граммотно разработанной программе невозможны так что и необходимость применения WDT практически равна нулю

 

 

проверяйте CRC программного кода

Проверяю

 

Здесь эта тема броде бы обсуждалась

Обсуждалась...А отслеживаю темы подобной тематики

[Johnny81 0]

Ну как вариант - расставить assert-ы по всей проге, для рантайм- проверки предусловий и постусловий функций. Если assert не выполняется - ахтунг.

[Liseev 0]

ИМХО, "случайные зависания" в граммотно разработанной программе невозможны

если в грамотно разработанной программе вы допускаете

что от помехи произошёл случайный переход из произвольной точки 1-го фрагмента кода в произвольную точку 2-го фрагмента кода

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

[Don_Ambrosio 0]

Ну как вариант - расставить assert-ы по всей проге, для рантайм- проверки предусловий и постусловий функций. Если assert не выполняется - ахтунг.

Что-то подобное и делаю.

 

 

Правда не знал, что эти переменные называются "assert-ы" :07:

 

если в грамотно разработанной программе вы допускаете

 

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

Допускаю...

Поэтому и тему создал тут http://electronix.ru/forum/index.php?showtopic=43223

 

Хотя реально.. Из опыта эксплуатации своих программ я увидел, что "случайных зависаний" не присходит, а вот "случайных джампов" сколько угодно

 

 

Вообще то я там WDRF искал и не находил :) . А обстановка с помехами там ещё та! Недалеко 6 кВ 1кА. И всё это тиристорами коммутируется.

Взято из поста #76 здесь http://electronix.ru/forum/index.php?showt...mp;#entry363289

[SapegoAL 0]

ИМХО, "случайные зависания" в граммотно разработанной программе невозможны так что и необходимость применения WDT практически равна нулю

 

Liseev писал вам правильно, а вы наводите тень на плетень. Естественно, ни о каких программных зависаниях речь не может идти. Но "зависание", как таковое, это не бездействие процессора. Если процессор "завис" после помехи или сбоя - это значит он попал в какой то цикл. Причём цикл обычный, "правильный", только в "неправильное" время. Из этого состояния его и вытягивает WDT.

 

Предложу вам свой метод вставки WDT.

 

1) Программа отлаживается полностью без WDT.

2) Анализируется текст программы. Выявляются минимальное число мест, где нельзя обойтись без сброса WDT. Надо чётко понимать, чем больше вы ввалите WDR, тем ниже вероятность выведения проца из ступора после сбоя (выше вероятность, что он зациклится там, где предусмотрен WDR).

3) Определяется минимальное время, достаточное для работы без "вылета".

4) Анализируются прерывания. (Здесь кто-то предлагал ставить WDR в регулярных прерываниях. На мой взгляд это возможный, но не самый лучший вариант)

5) В местах установки вами WDR желательно программно анализировать остальные параметры работы программы. Например известные признаки разрешения прерываний, максимальная длительность нахождения программы в том или ином цикле и так далее.

6) Программа инициализации должна анализировать состояние и причину сброса. Должна обеспечивать полную инициализацию всего используемого оборудования, включая умолчания. Сама инициализация должна проводится максимально быстро либо обеспечивать "теневую" работу. Иными словами, в оптимале, чтобы пользователь не замечал пересброса системы.

 

Тестируется.

[Don_Ambrosio 0]

Liseev писал вам правильно, а вы наводите тень на плетень.

Странный у вас метод ведения дисскусии

 

 

Но "зависание", как таковое, это не бездействие процессора.

Да что Вы говорите...Прям открытие для меня сделали..А я прям не знал

 

Если процессор "завис" после помехи или сбоя - это значит он попал в какой то цикл. Причём цикл обычный, "правильный"

Ещё раз повторяю (Вы что не читатель? Почему я должен повторять?):

В правильно разработанной (грамотной) программе таких циклов (а значит и зависаний) быть не может!!!

 

 

Предложу вам свой метод вставки WDT.

 

1) Программа отлаживается полностью без WDT.

2) Анализируется текст программы. Выявляются минимальное число мест, где нельзя обойтись без сброса WDT. Надо чётко понимать, чем больше вы ввалите WDR, тем ниже вероятность выведения проца из ступора после сбоя (выше вероятность, что он зациклится там, где предусмотрен WDR).

3) Определяется минимальное время, достаточное для работы без "вылета".

4) Анализируются прерывания. (Здесь кто-то предлагал ставить WDR в регулярных прерываниях. На мой взгляд это возможный, но не самый лучший вариант)

5) В местах установки вами WDR желательно программно анализировать остальные параметры работы программы. Например известные признаки разрешения прерываний, максимальная длительность нахождения программы в том или ином цикле и так далее.

6) Программа инициализации должна анализировать состояние и причину сброса. Должна обеспечивать полную инициализацию всего используемого оборудования, включая умолчания. Сама инициализация должна проводится максимально быстро либо обеспечивать "теневую" работу. Иными словами, в оптимале, чтобы пользователь не замечал пересброса системы.

 

И как всё это можно применить в многозадачной среде RTOS?

http://electronix.ru/forum/index.php?showtopic=43223

[galjoen 0]

mov R16 , $98

 

Такой команды у AVR нет.

5) В местах установки вами WDR желательно программно анализировать остальные параметры работы программы. Например известные признаки разрешения прерываний, максимальная длительность нахождения программы в том или ином цикле и так далее.

+1

Добавлю. Желательно анализировать стек. Если это в основном цикле (а там и стоит ставить WDR) то ук-ль стека д.б. = RAMEND (или как вы его установили). А если это подпрограмма (прерывание) - то диапазон разрешённых значений указателя стека (RAMEND-X)..(RAMEND-2) (с некоторым запасом). А ещё, что в вершине стека лежит. Откуда эта подпрограмма (прерывание) была. вызвана. Тоже диапазон.

 

Работает

[SapegoAL 0]

Ещё раз повторяю (Вы что не читатель? Почему я должен повторять?):

В правильно разработанной (грамотной) программе таких циклов (а значит и зависаний) быть не может!!!

 

Вы даже не понимаете что вы пишете. Не понимаете самой сути зависания, а ещё пытаетесь ехидничать. Через год перечитаете свои топики - будет стыдно.

 

Ладно попытаюсь вам объяснить.

 

Представьте себе правильно написанную программу, которая отработана и не содержит не единой ошибки. В ней находится следующий текст например:

 

...
ReadLptEPP:
    sbic    pinc,LptSTB    ; Строб пришёл?
    rjmp    ReadLptEPP    ; иначе повторить
    sbic    pine,WRITE    ; Если запись HOST, то продолжить
    rjmp    errLptEPP    ; иначе ошибка
    in        wl,ILPT        ; ввод данных в wl
    sbi        portc,WAIT    ; подтвердить
rwaitNoLptSTB:
    sbis    pinc,LptSTB    ; Строб сняли?
    rjmp    rwaitNoLptSTB; иначе повторить
    cbi        portc,WAIT    ; подтвердить
    ret
...

 

Теперь представьте себе что произошёл сбой в работе процессора и программа попала в ReadLptEPP либо rwaitNoLptSTB. Не по логике работы программы, а по сбою. Если для вас это непонятно, то представьте, что произошла ошибка во время перехода процессора, либо во время сбоя исказился PC, либо исказился стек и произошёл возврат не туда. Ну что доступно объясняю? Более того чтобы не исказилось и кудабы проц не пошёл, то он заткнётся в каком-нибудь цикле!!!! Это то понятно? В любой программе правильно написаной десятки либо тысячи циклов. Что тут непонятно? Но если ваша программа, например, сидит в цикле ожидания символа из UARTа, а он туда не должен придти, по той банальной причине, что вы не делали запроса и не потому что программа неправильно написана, а потому, что произошёл сбой и программа попала туда, куда не должна была попасть.

 

Что тут не ясно?

[Don_Ambrosio 0]

Что тут не ясно?

Мне всё ясно... Вы привели продемонстрировали сейчас КАК НЕ НАДО ПИСАТЬ ПРОГРАММЫ на примере неправильной организации программы..Я Вам еще раз повторяю: в граммотно спроектированной программе вечных циклов быть не должно не при каких искажениях данных и регистров!!!!

 

 

 

во время сбоя исказился PC, либо исказился стек и произошёл возврат не туда

Вот в этом, собственно, и вопрос темы. Как спроектировать программу, чтобы она детектировала приведённые Вами явления. Надеюсь из моих объянений и примеров Вы поняли, что Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны

 

 

Хочу заметить, Господа что я прекрасно себе представляю, что абсолютно все случаи несанкционированного использования кода программно обнаружить невозможно (а может есть MCU с аппаратной реализацией деления и защиты кода во FLASH?).

 

Такой команды у AVR нет.

Согласен.. описАлся

 

 

Если это в основном цикле

Какой ещё основной цикл в многозадачной многопоточной среде RTOS? И там стеков не один, а несколько...Причём как стеки PC, так и стеки данных

[SapegoAL 0]

Мне всё ясно... Вы привели продемонстрировали сейчас КАК НЕ НАДО ПИСАТЬ ПРОГРАММЫ на примере неправильной организации программы....

 

Надеюсь из моих объянений и примеров Вы поняли, что Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны

Хочу заметить, Господа что я прекрасно себе представляю, что абсолютно все случаи несанкционированного использования кода программно обнаружить невозможно (а может есть MCU с аппаратной реализацией деления и защиты кода во FLASH?).

 

Простите пожалуйста О ВЕЛИКИЙ.

Мне надо ещё долго учиться правильности написания программ. А также правильности её организации.

Да вот ещё незадача - разработчики компилятора C IAR (а я по своей дурости его использую как и тысячи других ещё вами не просвещённых) в своих библиотеках тоже совершенно безграмотно пишут. Например при обращении к EEPROM. Безусловно надо всё переписать. Завтра же возьмусь. Правда придётся заказывать новые чипы, так как новый правильный код в старые увы не влезет.

 

Да и завтра же отпишусь на Atmel, Intel, Dallas, Philips, TI и прочие конторы, что для правильно написанной программы "Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны".

 

С уважением,

ваш почитатель.

[Don_Ambrosio 0]

Простите пожалуйста О ВЕЛИКИЙ.

Мне надо ещё долго учиться правильности написания программ. А также правильности её организации.

Да вот ещё незадача - разработчики компилятора C IAR (а я по своей дурости его использую как и тысячи других ещё вами не просвещённых) в своих библиотеках тоже совершенно безграмотно пишут. Например при обращении к EEPROM. Безусловно надо всё переписать. Завтра же возьмусь. Правда придётся заказывать новые чипы, так как новый правильный код в старые увы не влезет.

 

Да и завтра же отпишусь на Atmel, Intel, Dallas, Philips, TI и прочие конторы, что для правильно написанной программы "Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны".

 

С уважением,

ваш почитатель.

А Вы ещё ИАРу напишите, что у них неправильный ИАР...

 

А вообще "нЕчего на зеркало пенять коли рожа кривая"(с) Если Вы не хотите чуть-чуть больше подумать на стадии проектирования программы, то тут уже Вам не ИАР, не Atmel ни кто-либо ещё уже не поможет

 

Кстати, Господа!! Хочу заметить вот что:

 

1) Вы мне хорошо расписали необходимость применения WDT в простейшей программе типа СуперЛуп и даже объяснили, где лучше вставлять команду сброса WDT для этого случая... Но при этом ничего не сказали о специфике применения WDT для случая многопоточных приложений в вытесняющей RTOS

2) Что можно применить кроме WDT высказлся только Непомнящий Евгений, а что же остальные?

 

Да и завтра же отпишусь на Atmel, Intel, Dallas, Philips, TI и прочие конторы, что для правильно написанной программы "Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны".

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

[galjoen 0]

Какой ещё основной цикл в многозадачной многопоточной среде RTOS? И там стеков не один, а несколько...Причём как стеки PC, так и стеки данных

А я про RTOS ничего и не писал. Прочтите внимательно!

И отвечал не вам, Дон Амброзио, а SasaVitebsk - и у него в том посте даже слова такого не было "RTOS".

 

А насчёт вечных циклов - согласен. Не должно их быть. Кроме основного (ну это не про RTOS, я RTOS не употребляю). Счётчик какой-нибудь уменьшаемый д.б. Если он до 0 досчитает - из этого цикла аварийный выход. Только вот куда выходить? Бывает, что это основной вопрос! Вот в таких случаях я стек и анализирую. Еще CRC16 той области ОЗУ, где глобальные настройки записаны, проверяю. Когда глобальная настройка изменяется - я CRC16 этой области конечно пересчитываю (при запрещённых прерываниях).

 

А для счётчика хорошо пара регистров R24, R25 подходит. Адресоваться по ним как по X, Y или Z нельзя, а команду sbiw R24,xx - применять можно. Перед циклом, где зависание теоретически возможно я пишу:

ldi R24,low(макс_кол-во_циклов)

ldi R25,high(макс_кол-во_циклов)

А в самом цикле:

sbiw R24,1

breq Аварийный_выход

Думаю и на C что-то подобное написать не проблема. Но я C для AVR не применяю. Попробовал - понял, что перед ассемблером преимуществ не вижу, одни недостатки. Хотя программы до 40 кБайт(20 кСлов) для AVR писал.

 

 

А вообще, ВЕЛИКИЕ - хватит ссорится!

[arttab 0]

Средства должны оправдывать цели.

уровень защиты от сбоя накладывает расходы (время, более "крутой" мк и пр.) на проект. можно дойти и до дублирования мажоритарности и пр.

Абсолютную защиту не создать да и не всегда она нужна.

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

Или здесь обсуждаются чисто теоретические обоснования устойчивой работы изделия при сбои мк? Может тогда сформулировать необходимые меры для разной степени устойчивости изделия?