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


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

Нормы эти, как и пайка солдатская, выработаны годами изучения вопроса. С достаточной степенью точности они описывают реальный мир. Кроме того, испытания в соответствии с данными нормами (испытания должны быть проведены соответствующей структурой, на соответствующем оборудовании, закончены выдачей соответствующих документов, подтверждающих соответствие) дают Вам полное право при наезде на Вас плана "у Вас устройство глючит из-за помех" замерить эти помехи непосредственно на объекте и при превышении просто послать заказчика на йух или, например, снять с него дополнительные деньги за доработку устройства под условия заказчика. Обычно заказчики идут на второй вариант, им спокойней.

Но хотел я не то сказать. Я уже писал про полсотни резисторов выше, видимо никто не прочитал пост. Хочу поставить вопрос так - на плате есть камень с надежностью, ну, 1e-5 и 50 резисторов с надежностью 1e-6 (это близкие к реальности цифры). Возникают 3 вопроса:
1. Какова общая надежность?
2. Что будет с результирующей надежностью, если надежность камня будет 1e-7 (например, программными методами)
3. (Задается после получения ответов на вопросы 1, 2) Стоит ли овчинка выделки?

Ведь PC не из особого теста леплен и если он сбивается, то сбиваются и все остальные регистры.

А если у нас без случайного джампа на Run произошло изменение DDRC и PORTC таким образом, что эти два сигнала выставвились. Ластик в руки и вперёд Конечно тут пора вспомнить, что мы не говорим о 100% ловле сбоев и говорим только о случайных джампах Но тут та собака и порыта:
1. Во многих применениях интересна 100% работа без сбоев, а сбоящие поделки быстро потеряют долю рынка.
2. Вероятность того что в случае помехи сбойнул только PC близка к нулю. А значит тема о случайных джампах бессмыслена.


p.s.
1. Про корпус это сильно, если на реальном объекте на корпус фазу подать или не заземлить, то будет уже не до вашей программы, если она конечно не ракеты пускает. А если она ракеты пускает, то такая ситуация с корпусом невозможна ибо думаю тама проверок на эту тему тьма.
2. Если резет оставить в воздухе и вашу тестовую программу загрузить в MCU, то зажигалку и на корпус вешать не прийдётся Вот где поле непаханное светодиод будет то зажигаться, то гаснуть.

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

Вот вот. Но эта точность - не 100%. Поэтому всегда сущестует вероятность ситуации, которая "бывает и хуже....Но реже ."...Т.е. проскочит например такая помеха раз в месяц. Ваш девайс глюканет и запустит "ядерную ракету". А Вы придёте измерять помеху. Неделю произмеряете и ничего не найдёте. А наследующий день бах. Опять такая помеха. Поэтому я не понимаю, почему многие из ответивших здесь на форуме так упорно сопротивляются против того, чтобы добавить надёжности девайсу (надёжности в смысле не предотвращения сбоев, а их своевременного обнаружения и устранения). Упираются ногами, руками, рогами и прочими частями тела. Почему?


Писал же уже Вы не четатиль, чтоли?

"А если подумать?
У меня "запуск ракеты" от одной команды невозможен. Ибо у меня железо выполено таким образом, что релюшка, запускающая "ядерную ракету" ( ) включается как минимум 2-мя пинами, сигналы на которых устанавливаются в разных точках программы. Так что даже если на один из пинов в результате сбоя будет подан сигнал "Enable RUN", то на другом-то пине такого сигнала не будет. И Америку не придётся с карты стирать ластиком "


Зачем спрашивать если Вы заранее знаете какой будет ответ при такой формулировке задачи?
Нет. Не стоит.

Но тут есть один нюанс. Что Вы понимаете под надёжностью MCU. Если вероятность выхода из строя какого-то его аппаратного узла, то это одно. А если вероятность сбоя из-за помех - это другое


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

Прибор или выполняет свои функции или не выполняет. На самом деле пофиг - отпал резистор или сбойнул камень.

Все-таки, подумайте над расчетом надежности Ваших устройств.



А с точки зрения квантовой теории и немыслимого

Я бы сказал, судя по теме, надежность камня где-то 1е-4



Пробовали. Случайно,конечно. А Вы что подумали?
И ничего страшного не происходит. Если нет свободных ног в Hi-Z состоянии, опять же.



Потому что тема трудно формализуется. И как говорил zltigo, актуальность этого вопроса является следствием ошибок на предыдущих этапах разработки.

Кой-чего вспомнил.
Прошлым летом один мой привод (кстати, движимый тривиальной мегой-8) залило водой. 380!!!
И что? И ничего: аппаратная защита от КЗ не дала начаться безобразию, проц рабочий, флеш целый, eeprom(!) целый, хотя возможность записи в программе есть. Нога какая-то второстепенная выгорела, не помню. Короче, ПРОСУШИЛ - ПОМЕНЯЛ ПРОЦ - ВПЕРЕД! Все живы по сей день.

Вот на это Вам ответит теория надежности.




Ничего подобного. Весь математический аппарат есть. Соответствующий раздел форума недалеко.

Ну кто ещё не "четатиль" это большой вопрос!

Я ж писал в предыдущем своём посте :



Вы читаете, что пишет Rst7? Похоже не всё!

А по поводу стороны проблемы затронутой Rst7 вот есть полезная статейка

Классика теории вероятности -
У блондинки спрашивают:
- Какая вероятность, что ты встретишь на улице динозавра?
- 50%. То ли встречу, то ли нет.

А по статейке выходит, что программа+проц = последовательное соединение блоков?

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

Почему вы считаете что вероятность случайного джампа выше чем выставление одновременно двух сигналов на порте? Ведь возможно ситуация когда вы всё проверили выставили первый сигнал и в этот же момент помеха выставила второй! Всё тупик.


Ну например если на корпус шкафа электроавтоматики попадёт фаза соприкосновение с ним радости не доставит


Неа мы ж тута обсуждаем безошибочные проги, которые ещё к тому же и исправляют баги глючных MCU:) Т.ч. надо брать надёжность MCU и надёжность MCU c меганадёжной прогой, которая ловит баги MCU

Согласен.. Просто надёжность в с смысле отсутствия необнаруженных сбоев от помех и постоянные (в смысле, не временные) отказы отдельных аппаратных узлов MCU - это другое.
Если 2-й параметр MCU и имеет такой же примерно порядок величины как , например, резистор. То первый хуже в 100 000 раз и более. Так что применение описанных мной методов обоснованно





А вы, Господа хорошие, вообще понимаете разницу между надёжностью программ и надёжностью железа? И что теория надёжности программ имеет свою специфику? Мне кажется что нет. Ибо тогда бы Вы знали, например, что понятие износа/старения , применяемое сплошь и рядом в теории надёжности железа, для программ не применимо.


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




Во-во.. И я про тоже... Некоторые Господа пытаются перенести все методики рассчёта надёжности железа и на программу. Забывая о том, что программа не имеет такого понятия как износ/старение

Ну вот приплыли
Мы же обсуждаем так сказать идеальные программы в которых всё предусмотрено(имеются ввиду все ситуации с бессбойным MCU) и каким образом не допустить, чтобы глюки MCU не испортили нам программной идеальности. Т.е как программным способом отловить аппаратный сбой, нарушающий ход выполнения программы или искажающий регистры или ОЗУ. Или я уже что-то не понимаю?


Мне кажеться это финиш.

Дык на всякую хитрую ж..у найдётся х..й с винтом... Это я к тому, что всегда существует верояность такой ситуации, когда уже ничего не поможет. И что? Если помогает в 99,99% случаев, а в 0,01% случаев не поможет. То такая защита не нужна?

Т.е. от ответа на вопрос Вы уклоняетесь. Значит разницу между надёжностью программ и надёжностью железа не понимаете. Тогда о чём тогда вообще вести речь?

Опять же, дело в цене вопроса. И если не трогать CALL / JMP, то остается проблема избавления от LDS/STS. Тоже, имхо, решаемая за счет использования LDD/STD. Но,блин, асм...

Исправил.

Сообщение отредактировал _Pasha - Feb 18 2008, 10:04

Вы не четатиль чтоли?
А зачем тогда я уже N раз в этой теме упомянал о разработанных мной тестовых программах и про то, что применённые мной методы давали значительный эффект, по сравнению с программами без использования методов обнаружения сбоев железа? Т.е. все свои предполжения и теоретические рассчёты я реально подтвердил на практике