Защита секция кода во FLASH в ATmega, Как защититься от несанкционированного выполнения кода Опции

[Дон Амброзио]

А кто как защищает код в 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

[arttab]

Средства должны оправдывать цели.
уровень защиты от сбоя накладывает расходы (время, более "крутой" мк и пр.) на проект. можно дойти и до дублирования мажоритарности и пр.
Абсолютную защиту не создать да и не всегда она нужна.
Если в случае сбоя мк будет остановлен с выводом кода ошибки, то будет видно что есть проблемы и можно попытаться выяснить какие, а автоперезапуск их скроет.
Или здесь обсуждаются чисто теоретические обоснования устойчивой работы изделия при сбои мк? Может тогда сформулировать необходимые меры для разной степени устойчивости изделия?

[Дон Амброзио]

Средства должны оправдывать цели.
уровень защиты от сбоя накладывает расходы (время, более "крутой" мк и пр.) на проект. можно дойти и до дублирования мажоритарности и пр.
Абсолютную защиту не создать да и не всегда она нужна.
Если в случае сбоя мк будет остановлен с выводом кода ошибки, то будет видно что есть проблемы и можно попытаться выяснить какие, а автоперезапуск их скроет.
Или здесь обсуждаются чисто теоретические обоснования устойчивой работы изделия при сбои мк? Может тогда сформулировать необходимые меры для разной степени устойчивости изделия?

Как Вы считаете, что более надёжно:

1) Вероятность сбоя устройства равна 10 в минус 9 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 50%
2) Вероятность сбоя устройства равна 10 в минус 3 степени; вероятность того, что этот сбой система не обнаружит (не зарегистрирует) и соотвтетственно не предпримит ни каких мер равна 0,0000001%

И что более надёжно? "Надёжная" система, сбои которой просто не обнаруживаются
или "ненадёжная" система, у которой 99,99999999% сбоев обнаруживаются и предпринимаются соответствующие меры по устранению их последствий


Как говорится: лучше перебдеть, чем недобдеть.

Ибо нафига мне "суперпупернадёжная" система, у которой происходит один сбой в год, но он НЕ ОБНАРУЖИВАЕТСЯ СИСТЕМОЙ. Я лучше возьму систему, у которой сбои происходят каждый день, ну у которой эти сбои НЕ ПРОХОДЯТ НЕЗАМЕЧЕННЫМИ СИСТЕМОЙ


Т.е. я предлагаю даже УХУДШАТЬ надёжность работы девайса за счёт увеличения вероятности обнаружения сбоя

Т.е. я предлагаю даже УХУДШАТЬ надёжность работы девайса за счёт увеличения вероятности обнаружения сбоя

Но это я конечно погорячился, но если встанет такая дилема - я пойду на это

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

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

[VladimirYU]

Ибо нафига мне "суперпупернадёжная" система, у которой происходит один сбой в год, но он НЕ ОБНАРУЖИВАЕТСЯ СИСТЕМОЙ. Я лучше возьму систему, у которой сбои происходят каждый день, ну у которой эти сбои НЕ ПРОХОДЯТ НЕЗАМЕЧЕННЫМИ СИСТЕМОЙ

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

[Дон Амброзио]

Как Вы думаете, что лучше вовремя принятое лекарство

Дык в описанных коллегами случаях ПРАВИЛЬНОГО лекарства и не будет поскольку диагноз не будет установлен