Защита секция кода во 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

[Liseev]

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

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

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

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

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

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

Проверяю

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

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

[Непомнящий Евген...]

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

[Liseev]

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

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

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

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

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

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

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


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

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

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

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

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

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

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

[SasaVitebsk]

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

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

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

1) Программа отлаживается полностью без WDT.
2) Анализируется текст программы. Выявляются минимальное число мест, где нельзя обойтись без сброса WDT. Надо чётко понимать, чем больше вы ввалите WDR, тем ниже вероятность выведения проца из ступора после сбоя (выше вероятность, что он зациклится там, где предусмотрен WDR).
3) Определяется минимальное время, достаточное для работы без "вылета".
4) Анализируются прерывания. (Здесь кто-то предлагал ставить WDR в регулярных прерываниях. На мой взгляд это возможный, но не самый лучший вариант)
5) В местах установки вами WDR желательно программно анализировать остальные параметры работы программы. Например известные признаки разрешения прерываний, максимальная длительность нахождения программы в том или ином цикле и так далее.
6) Программа инициализации должна анализировать состояние и причину сброса. Должна обеспечивать полную инициализацию всего используемого оборудования, включая умолчания. Сама инициализация должна проводится максимально быстро либо обеспечивать "теневую" работу. Иными словами, в оптимале, чтобы пользователь не замечал пересброса системы.

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

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

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

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

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

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

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

Ещё раз повторяю (Вы что не читатель? Почему я должен повторять?):
В правильно разработанной (грамотной) программе таких циклов (а значит и зависаний) быть не может!!!

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

1) Программа отлаживается полностью без WDT.
2) Анализируется текст программы. Выявляются минимальное число мест, где нельзя обойтись без сброса WDT. Надо чётко понимать, чем больше вы ввалите WDR, тем ниже вероятность выведения проца из ступора после сбоя (выше вероятность, что он зациклится там, где предусмотрен WDR).
3) Определяется минимальное время, достаточное для работы без "вылета".
4) Анализируются прерывания. (Здесь кто-то предлагал ставить WDR в регулярных прерываниях. На мой взгляд это возможный, но не самый лучший вариант)
5) В местах установки вами WDR желательно программно анализировать остальные параметры работы программы. Например известные признаки разрешения прерываний, максимальная длительность нахождения программы в том или ином цикле и так далее.
6) Программа инициализации должна анализировать состояние и причину сброса. Должна обеспечивать полную инициализацию всего используемого оборудования, включая умолчания. Сама инициализация должна проводится максимально быстро либо обеспечивать "теневую" работу. Иными словами, в оптимале, чтобы пользователь не замечал пересброса системы.

И как всё это можно применить в многозадачной среде RTOS?
http://electronix.ru/forum/index.php?showtopic=43223

[galjoen]

mov R16 , $98

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

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

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

Работает

[SasaVitebsk]

Ещё раз повторяю (Вы что не читатель? Почему я должен повторять?):
В правильно разработанной (грамотной) программе таких циклов (а значит и зависаний) быть не может!!!

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

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

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

Код

...
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а, а он туда не должен придти, по той банальной причине, что вы не делали запроса и не потому что программа неправильно написана, а потому, что произошёл сбой и программа попала туда, куда не должна была попасть.

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

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

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

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

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

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


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

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

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

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

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

[SasaVitebsk]

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

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

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

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

С уважением,
ваш почитатель.

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

Простите пожалуйста О ВЕЛИКИЙ.
Мне надо ещё долго учиться правильности написания программ. А также правильности её организации.
Да вот ещё незадача - разработчики компилятора 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]

Какой ещё основной цикл в многозадачной многопоточной среде 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]

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

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

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

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

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

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


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

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


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

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

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

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

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

[VladimirYU]

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

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

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

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

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

[Непомнящий Евген...]

ИМХО, стратегия поведения после обнаружения ошибки целиком зависит от назначения устройства. Иногда лучше молча перезагрузиться, иногда - сообщить об ошибке и остановить работу...

[VladimirYU]

ИМХО, стратегия поведения после обнаружения ошибки целиком зависит от назначения устройства. Иногда лучше молча перезагрузиться, иногда - сообщить об ошибке и остановить работу...

+1

[SasaVitebsk]

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

У меня есть изделие - модемы на пуле в телекоме. Так вот уже скоро 10 лет будет как они не выключаются. За это время три раза источники менял - кондёры высыхают. Предыдущие стояли - неделю отработать не могли.

Короче давайте спорить о вкусе устриц с теми кто их ел.

Перепиши пожалуйста мой бездарно написанный кусок проги из 10 строчек на одарённо написанный - хочу увидеть. Раз ты разглагольствуешь - должен же ты отвечачь за свои слова. Хотябы немного. Я думаю там совершенно понятен смысл.

Я жду.

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

У меня есть изделие - модемы на пуле в телекоме. Так вот уже скоро 10 лет будет как они не выключаются. За это время три раза источники менял - кондёры высыхают. Предыдущие стояли - неделю отработать не могли.

Короче давайте спорить о вкусе устриц с теми кто их ел.

Перепиши пожалуйста мой бездарно написанный кусок проги из 10 строчек на одарённо написанный - хочу увидеть. Раз ты разглагольствуешь - должен же ты отвечачь за свои слова. Хотябы немного. Я думаю там совершенно понятен смысл.

Я жду.

А Вы вообще кроме себя тут кого-нибудь читаете?

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

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

Вот Вам ответ.. От себя лишь добавллю термин "счётчик-ограничитель количества итераций цикла" Вам о чём-нибудь говорит?

[adc]

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

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

Да будет Вам известно что для WDT в некоторых контроллерах есть отдельный вектор прерывания по переполнению WTD, который позволит проанализировать сбой не выводя программу на общий reset.

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

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

Да будет Вам известно что для WDT в некоторых контроллерах есть отдельный вектор прерывания по переполнению WTD, который позволит проанализировать сбой не выводя программу на общий reset.

Мне это хорошо известно.. Но я с такими пока не работал...

А что это у нас дискусиия зациклилась на обсуждении WDT? Тема то у нас гораздо шире.. Или просто никто больше не знает других методов "борьбы" с явлением, указанном в названии темы?

[Kris2007]

А че такое бывает чтобы из-за электромагнитных помех грохнулся счетчик команд?
По моему это неудачные попытки нати существующую ошибку в коде. Не нашли списали на э.м помехи.

Импульсник на 3квт делали на атмеге. Там тАкие помехи идут и все ок. Я уж не говорю о других устройствах. Если некая помеха по питанию и на пине это еще понятно но случайная запись в PC ..

Сообщение отредактировал Kris2007 - Feb 12 2008, 13:26

[SasaVitebsk]

Мне это хорошо известно.. Но я с такими пока не работал...

А с какими ты работал? Сейчас практически все AVR "такие". Это когда-то на 1200 мне приходилось выкручиваться определяя источник.

А что это у нас дискусиия зациклилась на обсуждении WDT? Тема то у нас гораздо шире.. Или просто никто больше не знает других методов "борьбы" с явлением, указанном в названии темы?

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

С чего ты взял, что я не ипользую таймауты к примеру? Потому, что ты не видишь счётчика бесконечных циклов? А вот такой вариант к примеру ты не встречал

Код

...
    lds    sek1,    s7; таймаут по S7
    ldi    tmess,    3; "NO CARRIER"
    ldi    wl,    CONNECTD
    rcall    oCTRL; Ловить "несущую"
...

Может я не просто ухожу из бесконечного цикла, но мне требуется ещё задавать максимальное ожидание и программировать вариант текстового сообщения при выходе?


А теперь ответь на простой вопрос, раз уж ты уходишь от переписывания моей процедуры.
1) Чем счётчик циклов лучше WDT?
И ещё пару. Данная процедура ждёт пока пойдёт сообщение от терминальной программы. Это сообщение может поступить, например через 40 минут.
2) Как настроить бесконечный цикл чтобы обеспечить данное требование? Или будем пересбрасывать работающую прогу?
Хорошо - упростим задачу. Например событие происходит через 3 минуты максимум. Допустим ты настроил на выход из бесконечного цикла на 4 минуты.
3) Нормально если у тебя устройство будет выходить из возможного виса через 5 минут?

Главное ответь на первый вопрос. Меня это очень интересует.

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

А че такое бывает чтобы из-за электромагнитных помех грохнулся счетчик команд?

Бывает, бывает. Молодой человек. Я написал тестовую прогу для ATmega8 которая представляет собой следующее:

.cseg
.org 0
;-----------------
.set Number = 0
;-----------------
Begin_Loop :
.set Number = Number +1
ldi R16 , Number
nop
...
nop
cpi R16 , Number
breq PC+0x02
rjmp Crash
;-----------------
.set Number = Number +1
ldi R16 , Number
nop
...
nop
cpi R16 , Number
breq PC+0x02
rjmp Crash
;-----------------
.set Number = Number +1
ldi R16 , Number
nop
...
nop
cpi R16 , Number
breq PC+0x02
rjmp Crash
;-----------------------
......
......
......
;-----------------
.set Number = Number +1
ldi R16 , Number
nop
...
nop
cpi R16 , Number
breq PC+0x02
rjmp Crash
;-----------------------
rjmp Begin_Loop
;-----------------------
Crash :

; Зажечь светодиод
...

; Остановиться
;------------------------
После подачи помехи в виде электромагнитной наводки от пьёзозажигалки мне удавалось как зажечь светодиод

Импульсник на 3квт делали на атмеге. Там тАкие помехи идут и все ок. Я уж не говорю о других устройствах. Если некая помеха по питанию и на пине это еще понятно но случайная запись в PC ..

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

А с какими ты работал? Сейчас практически все AVR "такие"

Не звизди..
"Все такие" говоришь? А как же ATmega 8, 8515, 8535, 64, 128..А?

А как же ATmega 8, 8515, 8535, 64, 128..А?

В них по WDT происходит полноценный сброс, а не прерывание

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

Дык с зависаниями или сбоями? Вы уж определитесь.. Ибо понятие "сбой" гораздо шире понятия "зависание"

раз уж ты уходишь от переписывания моей процедуры.

Странный ты.. Ну на тебе твою переделанную процедуру (хотя я же объяснял тебе выше как это сделать. Неужели для тебя это так сложно? )

...
ldi R25 , high ( Border_Counter)
ldi R24 , low ( Border_Counter)
ReadLptEPP:
sbiw R25:R24 , 1
breq Crash
sbic pinc,LptSTB ; Строб пришёл?
rjmp ReadLptEPP ; иначе повторить
...

[SasaVitebsk]

Не звизди..
"Все такие" говоришь? А как же ATmega 8, 8515, 8535, 64, 128..А?

В них по WDT происходит полноценный сброс, а не прерывание

Используйте m88, m165, m1281...

Дык с зависаниями или сбоями? Вы уж определитесь.. Ибо понятие "сбой" гораздо шире понятия "зависание"

А что по вашему есть "зависание"?

Странный ты.. Ну на тебе твою переделанную процедуру (хотя я же объяснял тебе выше как это сделать. Неужели для тебя это так сложно? )

...
ldi R25 , high ( Border_Counter)
ldi R24 , low ( Border_Counter)
ReadLptEPP:
sbiw R25:R24 , 1
breq Crash
sbic pinc,LptSTB ; Строб пришёл?
rjmp ReadLptEPP ; иначе повторить
...

На частоте 14745600 максимальное время - 22мс. При 4-ёх байтном счётчике ~ 40 минут.
Итак вопрос чем ваш вариант лучше применения WDT? Не будем здесь обсуждать 1.5 кратное увеличение длины кода и прочие нюансы. Вчём прелесть? Я действительно хочу понять вашу мысль.

Дело в том, что некоторые применяют как раз противоположные подходы. К примеру, для перехода в 0 инициализируют WDT и делают цикл. Вот как раз отрывок из Atmel-овского avr231

Код

                        case TYPE_RESET:
                            busReplyByte(ERROR_OK);
                            for(;;);

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

К примеру, для перехода в 0 инициализируют WDT и делают цикл.

Это не для "перехода в 0" делается , а для перевода микроконтроллера в определённое исходное состояние, именуемого сбросом

Используйте m88, m165, m1281...

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

А что по вашему есть "зависание"?

Вы точно не читаете то, что уже написано. Я же написал выше, что " понятие "сбой" гораздо шире понятия "зависание"". Из чего следует, что зависание - это частный случай сбоя и зависание далеко не исчерпывает все возможные виды сбоев

[Rst7]

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

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

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

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

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

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

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

Вот вот

Но, я так понимаю, к Вам это не относится.

Откуда такие выоды

будете всю жизнь мучаться

Чуть-чуть пошевелить мозгами для Вас мучение?
Ну не знаю, не знаю.. А для меня в кайф когда проблема сложная

[SasaVitebsk]

Вы точно не читаете то, что уже написано. Я же написал выше, что " понятие "сбой" гораздо шире понятия "зависание"". Из чего следует, что зависание - это частный случай сбоя и зависание далеко не исчерпывает все возможные виды сбоев

А что именно здесь читать? Вы считаете что вы ответили на вопрос? С моей точки зрения вы его обошли. Правда не удачно.

"Зависание" - это не частный случай сбоя, а это частный результат сбоя. Их (результатов) может быть всего два вида. Первый - вылет на сброс, второй - "зависание" (зацикливание). Причём понятно, что проц не сразу туда попадает, а с момента сбоя - попадает в ближайший цикл, который не может пройти.

Видете как просто? По объёму написанного - столько же. Так почему просто не ответить на поставленный вопрос?

Далее - исходя из этого - WDT лучше помогает чем ваши ограничители. Какой в них смысл? Таймауты применяют при работе с внешним оборудованием, для того, чтобы диагностировать сбой в работе оного. Диагностировать, для того чтобы обработать ошибку определённым образом. Например если не получили ответа от rs485, посылаем повторный запрос, если произошёл сбой при работе с ЖКИ - сбрасываем и перерисовываем. Но если в результате "не ответа" нечего делать? Если уровень сбоя превышает возможности его обработки, в этом случае идёт полная перезагрузка процессора. И аппаратный аварийный рестарт - всегда был более лучшим средством чем программный.

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

Их (результатов) может быть всего два вида. Первый - вылет на сброс, второй - "зависание" (зацикливание).

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

Причём понятно, что проц не сразу туда попадает, а с момента сбоя - попадает в ближайший цикл, который не может пройти.

Видете как просто?

Такая простота хуже воровства и граничит с полной профессиональной некомпетентностью

попадает в ближайший цикл, который не может пройти.

Да нет таких в нормальной продуманной программе. Сколько раз Вам повторять

Таймауты применяют при работе с внешним оборудованием

А в многопоточных RTOS не применяется? У меня наприммер в моих программах работающих в среде моей же RTOS я контролирую до 50-ти таймаутов различных внешних и внутренних событий

[SasaVitebsk]

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

Давайте также затронем проблему сбоев в свете глобального потепления, а также влияние этих сбоев на пищеварение человека в условиях весенного недостатка витаминов в организме. Тогда у форумчан будет более полное представление об этом сложном и многогранном поведении кремния.

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

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

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

Спасибо Вам большое...Я давно уже хотел Вам это предложить... Да стеснялся.. Боялся Вас обидеть... Я конечно благодарен Вам за ликбез по использованию WDT (о которой я разумеется за более чем 15 лет работы с MCU и понятия не имел).

P.S. Жаль только что дисскуссия в этой теме зациклилась вокруг WDT (я рассчитывал услышать чего-нибудь новенькое, а тут опять про WDT) и Вы сработали сейчас ватчдог таймером и вывели дисскуссию (я надеюсь) из этого цикла

[arttab]

хорошо что не подрались...

может для начала определить с какими сбоими в работе мк боремся и в серии или до.

например можно создать следующие темы:
- изменение PC внешним воздействием и как и нужно ли с этим бороться;
- сбой работы АЛУ .....;
- отказ АЛУ....;
- сбой чтения из flash;
- выход из строя ячеек flash.

и средства борьбы можно разделить на внешние (по отношению к мк и внутренние - программные и аппаратные).

вопрос интересный и важный

[adc]

Странный ты.. Ну на тебе твою переделанную процедуру (хотя я же объяснял тебе выше как это сделать. Неужели для тебя это так сложно? )
...
ldi R25 , high ( Border_Counter)
ldi R24 , low ( Border_Counter)
ReadLptEPP:
sbiw R25:R24 , 1
breq Crash
sbic pinc,LptSTB ; Строб пришёл?
rjmp ReadLptEPP ; иначе повторить
...

Всегда пишу именно так, но хочу заметить что попав в результате сбоя, к примеру, на метку ReadLptEPP (не загрузив константы в регистры) можно превысить допустимое значение ожидание со всеми вытекающими из этого последствиями.
Предпочитаю использовать WDT + обязательный выход из цикла по переполнению описанный Вами.

[tyro]

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

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

Извините, что возможно немного не по теме. Обсуждается Защита секции кода во FLASH. Вероятность сбоя устройства равна 10 в минус 9 степени - это вероятность сбоя устройства из-за сбоя программы ? На каком интервале определена эта вероятность ( на выполнение одной команды, времени жизни всего устройства)? Сбой в программе отдельно взятого МК в системе приводит к 100% сбою системы ( это я к тому, что сначала рассматривалась программа, но вероятность ошибки в самой программе не рассматривается, долее говориться об устройстве а спрашивается о системе)?

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

Всегда пишу именно так, но хочу заметить что попав в результате сбоя, к примеру, на метку ReadLptEPP (не загрузив константы в регистры) можно превысить допустимое значение ожидание со всеми вытекающими из этого последствиями.

Согласен.. Просто я привык уже работать в среде мной же разработанной RTOS, где любой поток может быть вытеснен другим более высокоприоритетным потоком вообще говоря на случайное время. И как в этом случае Вы рассчитаете на сколько должен быть запрограммирован WDT? Поэтому в этом случае счётчик ограничитель количества итераций выглядит более предпочтитетельным. Тем более бывают задачи, где важно именно количество итерация цикла, а не время его выполнения

Предпочитаю использовать WDT + обязательный выход из цикла по переполнению описанный Вами.

Хорошее решение.. Но только для программ не работающих в RTOS с вытесняющей многозадачностью.
Я же использую в многозадачной среде виртуальные таймеры и WDT, которые фактически являются обратными счётчиками CPU_Time потока. Т.е. у меня любой поток может посмотреть в любой момент своё CPU_Time - время, которое бы он выполнялся если бы он были один в системе. Фактически CPU_Time - это счётчик тактов выполнения кода потока. Отсюда можно делать следующее. Вы прикидываете сколько максимальное количество тактов будет выполняться поток от точки A до точки B. Инициализируете в точке A виртуальный WDT, а в точке B его реинициализируете новым значением. Если этот виртуальный WDT обнулиться до прихода CPU в точку B потока, то это сбой и система это отработает. Кроме максимального времени работы некоторого участка кода, которое контролируется виртуальным WDT. Я ещё контролирую минимальное.. Ведь если известно, например, что подсчёт CRC 256-ти байтного пакета не может быть меньше 547788 тактов (цифры взяты просто для иллюстрации примера) и мы попадаем на точку завершения подсчёта и видим, что этот участок кода выполнился за 10790 тактов - то ясно же что имеет место сбой....

хорошо что не подрались...

Да млин, всё-таки неприятно, когда человек не врубившись "что почём" начинает меня "мордой тыкать" в такую элементарщину, что создаётся впечатление, что либо человек меня принимает за полного ламера (и это с моим-то более чем 15-ти летним опытом разработчика девайсов на базе MCU) либо сам таковым и является

может для начала определить с какими сбоими в работе мк боремся ...

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

Среди основных причин этого сбоя можно назвать следующие:
1) Случайное изменение значение счётчика команд из-за помех
2) Случайное изменение содержимого в ячейке ОЗУ в области, где храниться таблица переходов
3) Случайное изменение ОЗУ стека или указателся стека, в результате чего после команд ret/reri мы "улетаем" не пойми куда


СЮДА Я НЕ ОТНОШУ те сбои в командах перехода, когда в программе содержиться ошибка, проявляющаяся в том, что при не которых наборах данных она вычисляет не верный адрес точки перехода

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

Среди основных причин этого сбоя можно назвать следующие:
1) Случайное изменение значение счётчика команд из-за помех
2) Случайное изменение содержимого в ячейке ОЗУ в области, где храниться таблица переходов
3) Случайное изменение ОЗУ стека или указателся стека, в результате чего после команд ret/reri мы "улетаем" не пойми куда
СЮДА Я НЕ ОТНОШУ те сбои в командах перехода, когда в программе содержиться ошибка, проявляющаяся в том, что при не которых наборах данных она вычисляет не верный адрес точки перехода

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

Сообщение отредактировал Дон Амброзио - Feb 13 2008, 09:05

[Schtirlitz]

Надо отделить мух от котлет. Ибо проблема надежности устройства не ограничивается только ПО микроконтроллера. Если у вас программные сбои происходят от разряда пьезозажигалки, то программа тут совершенно не причем- все проблемы решаются правильной трассировкой. Для этого и существуют испытания на ЭМС и разные группы жесткости устройств.

ИМХО для программиста достаточно встроенного WDT (правда некоторые спецы по надежности советуют использовать внешний) и грамотно написанной программы.

Вероятность отказа устройства 10 в минус 9 степени - это попахивает авиацией, резервированием и прочими усложнениями:-))
Для "гражданских" устройств 10 в минус 5 степени уже хорошо.

Сообщение отредактировал Schtirlitz - Feb 13 2008, 09:32

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

Обсуждается Защита секции кода во FLASH. Вероятность сбоя устройства равна 10 в минус 9 степени - это вероятность сбоя устройства из-за сбоя программы ?

Вероятность сбоя устройства, явившегося причиной в сбое программы

Вероятность сбоя устройства равна 10 в минус 9 степени - это вероятность сбоя устройства из-за сбоя программы ? На каком интервале определена эта вероятность ( на выполнение одной команды, времени жизни всего устройства)?

Я же писал.. В течение года работы девайса.. А вообще Вы на цифры не обращайте - они взяты мной просто для иллюстрации моего примера

Сбой в программе отдельно взятого МК в системе приводит к 100% сбою системы

Согласен. Просто "система" в простейшем случае может состоять из одного МК и светодиода

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

Постепенно всё выясним.. Следите за темой

Вероятность отказа устройства 10 в минус 9 степени - это попахивает авиацией, резервированием и прочими усложнениями:-))
Для "гражданских" устройств 10 в минус 5 степени уже хорошо.

Повторю и для Вас: цифры взяты "от балды" просто для иллюстрации приведённого выше примера

[adc]

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

Вы спрашивали почему тут все уперлись в WDT?. Объясняется это тем что это решение практически на уровни железа. Как можно программными методами отследить случайный переход на случайную точку программы? Даже если в программе большая часть функций направлена на контроль правильности выполнения кода, ни что не защитит программу от перехода на случайный адрес с последующим нарушением нормальной работы устройства.
Как мне кажется решение должно быть на уровне железа.. (внешние контролирующие устройства(тотже только внешний WDT), дублирующий контроллер(возможно выполняющий туже задачу) и т.п.) Это мое ИМХО.

[galjoen]

Всегда пишу именно так, но хочу заметить что попав в результате сбоя, к примеру, на метку ReadLptEPP (не загрузив константы в регистры) можно превысить допустимое значение ожидание со всеми вытекающими из этого последствиями.
Предпочитаю использовать WDT + обязательный выход из цикла по переполнению описанный Вами.

В реальной задаче, я пишу это так:

ldi R25 , high ( Border_Counter)
ldi R24 , low ( Border_Counter)
ReadLptEPP:
cpi R25, 1+high ( Border_Counter)
brcc Crash1
sbiw R25:R24 , 1
breq Crash2
sbic pinc,LptSTB ; Строб пришёл?
rjmp ReadLptEPP ; иначе повторить
...

В том посте я про cpi R25, 1+high ( Border_Counter) просто не упомянул. Можно конечно R25:R24 сравнивать с Border_Counter+1, но это уже не обязательно. А код и время добавляет.

А вообще все важные переменные (а к ним счётчики однозначно относятся) обязательно на диапазон проверяю. Это как минимум. Те переменные, которые редко меняются, храню в области ОЗУ защищённой CRC. Это CRC я при изменении переменной перерассчитываю (cli). А в основном цикле (не RTOS) по 1 байту за цикл их CRC считаю и потом сравниваю. А те переменные, которые часто меняются, их инверсией защищаю. Например переменная 4 байта, и её инверсия 4 байта. Когда пользуюсь - ксор с инверсией побайтно делаю, и на FF проверяю. Кстати у меня всегда два регистра из R2..R15 имеются, которые я один раз устанавливаю, и больше не меняю. Одим равный 0x00 (RG00), другой FF (RGFF). Так вот, чтоб переменную в регистры R16..R19 загрузить, пишу обычно так:

ldi YL,low(VarXX)
ldi YH,high(VarXX)
ld R16,Y
ldd R20,Y+4
eor R20,R16
cpse R20,RGFF
rjmp Crash
ldd R17,Y+1
ldd R20,Y+5
eor R20,R17
cpse R20,RGFF
rjmp Crash
...

А ещё хочу сказать, что все ожидания более 0.05 мС, обязательно нужно в основной цикл (не RTOS) переносить!!! И если не готово - к другой задаче переходить. Там что-то ждётся - к следующей и т.д. Какие уж там 4 секунды ожидания!!!
Но если уж 4 секунды - где, в таком случае, в том цикле, который все дружно переписывали, столь любимая SasaVitebsk-ом, команда wdr???
Кстати с wdr у атмела глюки. В описании написано, что при WDP2=WDP1=WDP0=1 типовое значение при 3В 2200 мС, при 5В 2100 мС. В реальности: от 1500 до 1800 мС. Я из-за этого на две секунды засыпать не могу - собака будит раньше чем RTC.
Я теми AVR пользуюсь, у которых собака=сбросу. Но даже если у собаки свой вектор будет - что это изменит? Что в обработке запуска нельзя WDRF проверить? Конечно в стеке адрес, откуда собака сработала, будет (если стек не навернулся). Но это только на этапе отладки имеет значение. В реальном устройстве это ничего не даст - все программные глюки д.б. уже устранены.

Но вот узнали мы, что щас Crash, а дальше-то делать-то что? По идее надо лог записать, и хорошо-бы восстановиться с наименьшими потерями.

А у меня такой вопрос: кто нибудь здесь лог-ги пишет???
И куда пишите?
Я-то пишу в AT45DB642D. Потом их как файл из MassStorage читаю. Так вот заметил, что флешка по помехозащищённости похуже чем AVR будет! Если помеха не одиночная, а пачкой идёт - нифига мне в AT45DB642D записать без ошибок не удаётся. Как будто, кто-то рукой сеятеля FF там рассыпал. В смысле в буфере 1056 байт. Причем кол-во FF нарастает во времени. Те данные, которые я последними пишу почти не страдают. А первые все FF-ми покрыты. Хотя, конечно, последние данные - они самые важные.

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

ИМХО для программиста достаточно встроенного WDT

Повторю и для Вас. Расскажите поподробней как использовать WDT в среде вытесняющей RTOS?

[zltigo]

Постепенно всё выясним.. Следите за темой

Схоласты занимаются некоторыми "проблемами" гораздо дольше, нежели Вы c Вашим "более чем 15-ти летним опытом". "Проблемы" не решены. За темой следить не вижу ни малейшего смысла.

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

Надо отделить мух от котлет. Ибо проблема надежности устройства не ограничивается только ПО микроконтроллера. Если у вас программные сбои происходят от разряда пьезозажигалки, то программа тут совершенно не причем- все проблемы решаются правильной трассировкой. Для этого и существуют испытания на ЭМС и разные группы жесткости устройств.

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

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

[Dog Pawlowa]

За темой следить не вижу ни малейшего смысла.

А как модератор?
Чем раньше будет заткнут очередной фонтан доктора Туамосеца, тем плодотворнее будет форум.
Пусть он лучше на порнушных сайтах пишет.

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

Как можно программными методами отследить случайный переход на случайную точку программы?

Вы задали вопрос, который собственно и должен "красной нитью" идти через всю тему. Ради того, чтобы услышать ответы участников форума на него я , собственно говоря, и создал эту тему

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

Согласен, что программа от таких сбоев не защищает, но она может помочь в их обнаружении и оповещении о них.

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

Как мне кажется решение должно быть на уровне железа.. (внешние контролирующие устройства(тотже только внешний WDT), дублирующий контроллер(возможно выполняющий туже задачу) и т.п.) Это мое ИМХО.

Моё ИМХО такое же.. Но всё же лучше "соломки подстелить". Ибо лучше перебдеть, чем недобдеть

За темой следить не вижу ни малейшего смысла.

А я никого и не заставляю читать эту тему или чтото писать в ней. Так же как оставляю за собой право НЕ ЧИТАТЬ и НЕ ОТВЕЧАТЬ в неинтересных мне темах

[Schtirlitz]

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

А как быть с вероятностью сбоя программы обнаружения сбоев?
Не нужно изобретать велосипед: если нужна вероятность отказа устройства 10 в минус 9-й степени - применяйте резервирование, мажоритарные схемы итд.

[zltigo]

А как модератор?

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

[galjoen]

Согласен, что программа от таких сбоев не защищает, но она может помочь в их обнаружении и оповещении о них.

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

+1

Как можно программными методами отследить случайный переход на случайную точку программы?
Я от этого контролем данных защищаюсь - см. мой предыдущий пост. Подсчётом их CRC, сравнением с инверсией и т.д.
ИМХО в случае несанкционированного перехода, данные и в регистрах и в ОЗУ, несоответствующие программе будут.
Это не 100% конечно. Но и CRC у порченных данных тоже совпасть может!
А если программа хотя-бы диапазоны данных проверяет - то и больших бед не натворит. И восстановиться потом можно будет!

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

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

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

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

[galjoen]

Я тут ещё старый анекдот вспомнил. Как раз в тему.
Один программист у другого спрашивает. Почему у тебя два одинаковых jmp подряд стоят? Тот отвечает. Это на случай того, что 1-й не сработает.
Однажды поймал себя на желании именно так и сделать! В смысле два одинаковых jmp подряд поставить!!!
Дон Амброзио и другие участники этой ветки, вы себя на таком желании не ловили? А может и ставили? Если так - значит я с вами одной крови.

[mig2002]

Возвращаясь к первоначальному вопросу могу посоветовать применить при написании программы теорию графов.
Нужно нумеровать состояния программы. При переходе в новое состояние, анализировать предыдущее и т.д.
На практике ввести переменную STATE, задавать ей значение только перед переходом в новое состояние.

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

А как быть с вероятностью сбоя программы обнаружения сбоев?

А для этого я использую такую организацию кода, когда все участки друг друга тестируют. Т.е. когда вся программа предстваляет собой как бы детектор сбоев и вся её организация направлена на то, чтобы как можно раньше определить наличие и причину сбоя. Хотя конечно разумеется никакие программные навороты не дадут 100% обнаружения сбоев.

Не нужно изобретать велосипед: если нужна вероятность отказа устройства 10 в минус 9-й степени - применяйте резервирование, мажоритарные схемы итд.

Я в курсе.

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

Как можно программными методами отследить случайный переход на случайную точку программы?

И как же ? По вашему мнению?


Я вот например имею некоторые мысли (даже не мысли, а реально работающие программы, в которых это отслеживается (с некоторой долей вероятности успеха разумеется)), но хотел бы услышать сперва Ваши

Возвращаясь к первоначальному вопросу могу посоветовать применить при написании программы теорию графов.
Нужно нумеровать состояния программы. При переходе в новое состояние, анализировать предыдущее и т.д.
На практике ввести переменную STATE, задавать ей значение только перед переходом в новое состояние.

Спасибо... Что-то подобное и делаю, только использую не STATE а регистр кода доступа к логическому сегменту

[adc]

Как можно программными методами отследить случайный переход на случайную точку программы?

Я от этого контролем данных защищаюсь - см. мой предыдущий пост. Подсчётом их CRC, сравнением с инверсией и т.д.
ИМХО в случае несанкционированного перехода, данные и в регистрах и в ОЗУ, несоответствующие программе будут.

Но ведь сравнение то у вас происходит на программом уровне а не на аппаратном! А если программа перескочит туда где нет проверки на совпадение CRC?
Потом проверка данных после каждой операции мне кажется несколько избыточной.

И как же ? По вашему мнению?

Есть предложение в начале каждой операции(подпрограммы) загружать в озу константы , а в конце считать контрольную сумму этих чисел и записывать также в озу. Далее по прерыванию от таймера(включенного при инициализации) проверять соответствие текущих констант в озу и их контрольной суммы. Если не соответствует принимать меры.
Конечно тоже не 100% метод... но всеже..

[mig2002]

В принципе, однозначного решения данного вопроса быть не может
Решение нужно выбирать для конкретной задачи. Можно ипользвать и программные методы, и аппаратные. Нужно только определиться с приоритетами: быстродействие или надежность. Хотя понятие надежности тоже относительное. А степень надежности должна определяться стоимостью обрабатываемой информации.

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

В принципе, однозначного решения данного вопроса быть не может

Оно и понятно. А Вы как решаете проблему обнаружения в программе несанкционированных переходов?

А степень надежности должна определяться стоимостью обрабатываемой информации.

Оно и понятно .. Нет смысла применять супер-пупер методы увеличения надёжности для управления ёлочной гирляндой

Можно ипользвать и программные методы, и аппаратные.

Разуметцо

Потом проверка данных после каждой операции мне кажется несколько избыточной.

А что Вам MCU жалко? Да бростье Вы..Он же железный... Пусть работает
А если серьёзно, то обоснованность применения избыточности кодирования и избыточности в затратах памяти, времени CPU и т.п. ресурсах определяется решаемой задачи... Реально делал когда у меня в одном процессоре работали 3 одинаковых потока, которые делали одно и тоже с 3-мя копиями одних и тех же данных. А потом результаты проверялись мажоритарным голосованием

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

Вообще сейчас скажу крамольную мысль (только чур не бить ногами)

Чем более чувствительна программа к аппаратным сбоям тем лучше

Т.е. если правильно и грамотно разработанная программа начинает ЗАМЕТНО глючить от каких либо помех, то это здорово. Потому что гораздо хуже если в программе чего-то глюкануло, а мы этого не заметили и считаем что всё ОК

[galjoen]

Но ведь сравнение то у вас происходит на программом уровне а не на аппаратном! А если программа перескочит туда где нет проверки на совпадение CRC?

Как я и писал там-же, я это делаю в основном цикле (не RTOS). По 1-му байту за цикл. На это меньше 20 тактов уходит. Из них сам подсчёт CRC16 - 10 тактов. А ухожу на восстановление только если два раза подряд CRC не совпало. А команда wdr у меня только в основном цикле стоит. Если я туда попадать перестану - собака сработает. Но ни разу ещё не срабатывала! У меня все логи пишутся.
А вот проверка CRC данных бывало срабатывала.

Потом проверка данных после каждой операции мне кажется несколько избыточной.

А я далеко не на все данные их инверсию завожу. А только на важнейшие. Несанкционированное изменение которых разрушительно скажется. Например N сектора в файле в который писать буду. И их в основном цикле ещё тоже перепроверяю. По 1й переменной за цикл. Это совсем быстро. Срабатывало.
А ещё в основном цикле CRC32 всей программы считаю. По 1-му слову за цикл. Ни разу не срабатывало.
А ещё если байтная переменная может иметь только несколько значений (< 86), я их не последовательно, а через 3, 5 или 7 увеличиваю. И за запрещёнными состояниями слежу. Срабатывало.

А вообще, всё это у меня началось после того, как я испытания на ЭМС прошел. Со 2й попытки. Всего лишь класс B. Но жесткость была максилальная. На наносекундных импульсах проблеммы были.
А у вас как с ЭМС? С наносекундными импульсами? Если скажете, что от них не сбивается (класс A) - не поверю!!!

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

Так красиво ответить на хамские посты, глубочайший respect!

А кто хамил? И где? И почему бы Вам свои благодарности было не написать в привате? Зачем тему-то замусоривать?

[defunct]

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

Вы же и так все знаете, зачем Вам еще что-то советовать?!

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

Горячий испанский парень.

Вот Вам ответ.. От себя лишь добавллю термин "счётчик-ограничитель количества итераций цикла" Вам о чём-нибудь говорит?

это еще что за зверь такой "счетчик ограничитель". В RTOS каждая задача - это бесконечный цикл.

Мне это хорошо известно.. Но я с такими пока не работал...

Слова дойстойные анекдота.

Тема то у нас гораздо шире.. Или просто никто больше не знает других методов "борьбы" с явлением, указанном в названии темы?

тема ваша тупая на самом деле, и в том виде в каком задача поставлена в первом посте - не имеет решения вообще.

Не звизди..

Куда смотрят модераторы?! Пора бы немного остудить гарячего парня.

( я последнее время больше программером работаю, хотя я могу и платы разводить, и схемы проектировать).

50% боксер / 50% сторожевая собака © какой-то мультик

Чуть-чуть пошевелить мозгами для Вас мучение?

опять хамство.

У меня наприммер в моих программах работающих в среде моей же RTOS

Спасибо Вам большое...Я давно уже хотел Вам это предложить... Да стеснялся.. Боялся Вас обидеть...

полное хамство.

А кто хамил? И где? И почему бы Вам свои благодарности было не написать в привате? Зачем тему-то замусоривать?

Вы. В каждом посте. Потому что меня Ваша манера ведения дискуссии просто бесит. Пришел всезнающий барин, и давай всем объяснять какаие они л...и., какой уж тут приват.
Тему эту уже не замусоришь, она и так замусорена вашими постами "от и до".

[Rst7]

А у вас как с ЭМС? С наносекундными импульсами? Если скажете, что от них не сбивается (класс A) - не поверю!!!

У меня стандарт на оборудование (EN54) требует не сбиваться, максимум - кратковременное нарушение индикации (ну типа, когда статразряд влетает в светодиод, он подмигивает ). И работает.

[mig2002]

Оно и понятно. А Вы как решаете проблему обнаружения в программе несанкционированных переходов?

Я использую и STATE, и WDT, и программные таймауты. А вообще стараюсь писать, чтобы была однозначность во всех ситуациях. А что касается несанкционированных помех и т.д., то эти вопросы лучше решать другими способами (экранами, фильтрами, убрать подальше от источника помех.....).

[IgorKossak]

Считаю своим долгом всем напомнить, что неплохо бы поостыть и прекратить обсуждать личности.

[adnega]

Недавно дорабатывал текстовое информационное табло. Разработчиком была допущена ошибка в проектировании ПП, в результате табло "ловило" помехи очень стабильно. Инженерам приходилось выезжать на место и пересбрасывать питание.

Во-первых, доработал программу. Табло реализовывало динамическую развертку (100Гц). В разверточном прерывании вставил WDR после проверки нескольких таймаутов. Логика такая:
1. Разверточное прерывание нужно всегда, т.е. это гарантированная точка входа с частотой 100Гц. Его задача разворачивать ВидеоОЗУ;
2. Поставил таймаут на прием данных по последовательному интерфейсу. Задача приемника принять данные и поместить их в буфер;
3. Поставил таймаут в MAINLOOP. В главном цикле проверялось пришли ли новые данные и при необходимости записывалось ВидеоОЗУ;
4. В разверточном прерывании проверял таймауты от приемника и главного цикла, если они не истекли, то сбрасывал сторожевой таймер.

Таким образом, я гарантировал, что разверточное прерывание будет всегда; не зависнет конечный автомат приемника (таймаут приемника) и принятые данные попадут в буфер; в главном цикле принятые данные из буфера перепишутся в ВидеоОЗУ, развертка которого гарантирована.

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

Вот.

[defunct]

После аппаратных доделок табло перестало ловить помехи.

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

[galjoen]

У меня стандарт на оборудование (EN54) требует не сбиваться, максимум - кратковременное нарушение индикации (ну типа, когда статразряд влетает в светодиод, он подмигивает ). И работает.

Рискну предположить, что у вас всё работает из-за того, что всё это достаточно большое, и в железном корпусе. Я это условие как-то в том посте упустил.
У меня-то пластмассовый корпус 120*60*32 мм. И когда они этот гвоздик, в котором 8 кВ за единицы наносекунд нарастает, к корпусу подносят (к разным местам), то до процессора и других микросхем - от него менее 15 мм расстояние. Это почище той зажигалки, которой Дон Амброзио свои процессоры тестирует. Пробовали экраны металлические делать - эффект 0-й, а удорожание не 0-е. И всё равно это не поможет т.к. кабеля-то наружу торчат. От них тоже сбивается.

Но всё само восстанавливается (класс B )

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

У меня тоже бутлоадер есть в области загрузчика. Перед тем как программировать я CRC переменных проверяю. Согласен, что защита не 100%. Может ведь и после проверки прыгнуть. Но 99.9%. А если быть точным - то отношение кол-ва команд с которых бутлоадер несанкционированно запустится к 65536 (столько слов у AVR с 128 в конце).

[Rst7]

У меня-то пластмассовый корпус 120*60*32 мм.

И в подобных корпусах есть приборчики. Там система будь-здоров, всяких разных приблуд и в пластмассовых корпусах и в металлических - дофига. Все работает.

[defunct]

Может ведь и после проверки прыгнуть. Но 99.9%. А если быть точным - то отношение кол-ва команд с которых бутлоадер несанкционированно запустится к 65536 (столько слов у AVR с 128 в конце).

угу, прыжек же "случайный" можно папасть в любую точку, по законам Мерфи попадем ровно на erase sequence после всех проверок. Защититься тут никак нельзя, а вот предотвратить "командировку для устранения последствий" - можно. Например, можно хранить копию основной прошивки во внешней eeprom'ке, при старте бутлоадером проверить CRC прошивки, если не совпадает - то попытаться загрузить прошивку из внешней eeprom.

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

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

угу, прыжек же "случайный" можно папасть с любую точку, по законам Мерфи попадем ровно на erase sequence после всех проверок.

Ага.. Но у меня в конце каждой итерации записи страницы стоит тоже проверка "а была ли действительно санкционирована запись" и если нет - восстанавливаем странцу из копии программы (у меня в флэшаке всегда храниться 3 копии программы: одна активированная, а 2 в дезактивированном виде)

Так что.. Опять мимо

Представим, что у нас в МК прошит бутлоадер. В нем есть потенциально фатальная для девайса команда стирания страницы флеш

Надо проектировать программу так, чтобы стирание одной единственной страницы флэш не было фатальным . Как? Смотрите выше

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

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

[galjoen]

И в подобных корпусах есть приборчики. Там система будь-здоров, всяких разных приблуд и в пластмассовых корпусах и в металлических - дофига. Все работает.

У меня есть знакомый. Очень уважаемый человек! Он всегда рассказывает, что огородом совсем не занимается, а там у него все очень хорошо растёт. При этом он явно даёт понять, что у него все растения так хорошо растут просто из уважения к нему.
Надеюсь, вы Rst7, не такой уважаемый человек. Объясните, как-же у вас в таких корпусах от наносекундных помех ничего не сбивается? Вы экраны ставите? Или как вы этого добиваетесь?

Только без обид. Rst7, заранее извиняюсь! Простите, что первое на ум пришло написал. А стирать жалко.

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

это еще что за зверь такой "счетчик ограничитель".

"На свете есть много такого, мой друг, Горацио, что и не снилось нашим мудрецам"(С)

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

Принимается

Я немного неправильно сформулировал задачу.

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


А правильно бы надо было так (ведь именно это меня и интересует):

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

Согласен, что защита не 100%.

Вот я и говорю, что не 100% но всё же эффект ведь налицо от применения "программных методов"
Что эти Господа так упираются против использования программных методов обнаружения сбоев? Не понимаю

А что касается несанкционированных помех и т.д., то эти вопросы лучше решать другими способами (экранами, фильтрами, убрать подальше от источника помех.....).

Конечно лучше... И плюс для подстраховки рассыпать в проге код обнаружения случайных джампов...Так...На всякий пожарный

[defunct]

(у меня в флэшаке всегда храниться 3 копии программы: одна активированная, а 2 в дезактивированном виде)

Так что.. Опять мимо

А почему Вы восприняли это на свой счет?
Я же не знал, что и как у Вас реализовано, и соотв. не мог критиковать вашу реализацию.
А вот сейчас уже могу - что делать если основная прошивка занимает >50% флеша?

На этом форуме вообще-то не принято друг-друга подкалывать.
Тему можно сделать интересной, и без скандальных постов.

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

Я же не знал, что и как у Вас реализовано, и соотв. не мог критиковать вашу реализацию.А вот сейчас уже могу - что делать если основная прошивка занимает >50% флеша?

1)Использовать другой MCU с бОльшим количеством FLASH
2)Уменьшить программу
3) Придумать что-то ещё(например выделить во FLASH какой-нибудь буфер страницы на 4; пишем новую страницу туда; пишем ещё одну копию новой страницы в буфер; затем считываем в ОЗУ содержимое старой страницы, которую хочем изменить; пишем её в буфер; ещё раз считываем в ОЗУ содержимое старой страницы; пишем её в буфер; далее стираем требуемую страницу и пишем новое содержимое ТАКИМ ОБРАЗОМ СТИРАНИЕ ОДНОЙ СТРАНИЦЫ FLASH НЕ БУДЕТ ФАТАЛЬНЫМ

На этом форуме вообще-то не принято друг-друга подкалывать.

И не думал. Ведь я как никто заинтересован этой темой и в нормальных ответах в ней, а не в обсуждении моей персоны

1)Использовать другой MCU с бОльшим количеством FLASH
2)Уменьшить программу
3) Придумать что-то ещё(например выделить во FLASH какой-нибудь буфер страницы на 4; пишем новую страницу туда; пишем ещё одну копию новой страницы в буфер; затем считываем в ОЗУ содержимое старой страницы, которую хочем изменить; пишем её в буфер; ещё раз считываем в ОЗУ содержимое старой страницы; пишем её в буфер; далее стираем требуемую страницу и пишем новое содержимое ТАКИМ ОБРАЗОМ СТИРАНИЕ ОДНОЙ СТРАНИЦЫ FLASH НЕ БУДЕТ ФАТАЛЬНЫМ
И не думал. Ведь я как никто заинтересован этой темой и в нормальных ответах в ней, а не в обсуждении моей персоны

К тому же между установкой бита SPMEN и командой SPM даётся 4 такта на "раздумье". Туда можно засунуть код:
OUT SPMCR , R16
; ---------------
SBRS R17 , 7
RJMP CRASH
;-----------------
SPM

ТАКИМ ОБРАЗОМ СТИРАНИЕ ОДНОЙ СТРАНИЦЫ FLASH НЕ БУДЕТ ФАТАЛЬНЫМ

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

[galjoen]

На этом форуме вообще-то не принято друг-друга подкалывать.

И не думал. Ведь я как никто заинтересован этой темой и в нормальных ответах в ней, а не в обсуждении моей персоны

А я Дон Амброзио спасибо хочу сказать. Только в этой ветке про STATE узнал. Теперь буду применять. Пусть некоторые меня после этого признания будут ламером считать. Сам-то я знаю, что я ого-го! А те, кто на безобидные приколы обижается, сами виноваты. Дон Амброзио - токо не надо меня прикалывать. Мы ведь с вами друзья...

[defunct]

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

Детектировать случайный переход из одной точки программы в другую своевременно и безболезненно для текущей выполняющейся программы невозможно. Стало быть вопрос лишь в масштабах последствий такого сбоя (по убыванию):
1. Нарушение памяти программ.
2. Нарушение содержимого регистров / памяти данных - в последствии к "подвисанию" неверной работе части программы.
3. Порча незначительных данных например пакета защищенного кодом защиты. (плохо конечно, но с этим можно смириться).
4. Чисто везение, прыжек в участок кода - который ничего не испортил (например из финализации одной функции в финализацию другой с подобными параметрами). Везение рассматривать не будем.

Итого лечить надо только 1 и 2.

Первое лечится с помощью дублирования кода программы. Определяется и устраняется эта ошибка при очередной перезагрузке устройства. Как правило после такого сбоя устройство перезагружается по WDT.

Второе - система продолжает работать но часть функций отказала. Лечится перезагрузкой, перезагрузка делается опять с помощью WDT.

Вопрос в том где и как сбрасывать WDT чтобы последствия сбоя были 100% устранены. Решить этот вопрос можно например введя мониторинг статуса каждой задачи. Если используется RTOS, то сделать это достаточно просто - idle task (задача с самым низким приоритетом) периодически оцнивает состояние каждой задачи, если все задачи в порядке - WDT сбрасывается. Состояние же каждой задачи должно определяться индивидуально, для каждой задачи свой отдельный таймаут.

Пусть имеется некое устройство, которое занимается опросом некоторых датчиков по одному интерфейсу, и отправляет результаты - по другому. Тогда работу этого устройства можно разбить на 5 задач:
1. idle (занимается контролем WDT)
2. обслуживание передачи по интерфейсу датчиков.
3. обслуживание приема по интерфейсу датчиков.
4. обслуживание передачи по интерфейсу хоста.
5. обслуживание приема по интерфейсу хоста.

Статус первой задачи всегда Ок (коль уж в нее попали, то стало быть она работает).
Статус 2-й задачи переходит в состояние Alert если счетчик отправленных пакетов не изменяется в течение заданного таймаута.
Статус 3-й задачи определяется таймаутом "за n секунд не принято ни одного байта"
Статус 4-й задачи определяется аналогично 2-й
и наконец статус 5-й - аналогично 3-й.

Если хотя бы одна задача не в порядке, то в задаче 1 запрещаем прерывания и подвешиваем систему циклом
while( K * WDT_CYCLE)
__no_operation();

где
WDT_CYCLE - константа, соответвующая количеству циклов эквивалентное интервалу WDT.
K - коэффициен >1, для гарантии сброса МК.

Если вдруг получается так, что мы выходим из этого цикла. Тогда WDT вероятно тоже сбойнул - пытаемся:
1. Выполнить аппаратный сброс (если заранее предусмотрели управление внешней схемой сброса).
2. Выполнить прыжек по RESET вектору (т.к. хуже уже все равно не будет).


PS: До сих пор, против "случайных прыжков" этих программных мер мне хватало с головой.

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

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

В корне не согласен с этой аксиомой(откуда Вы это взяли). 100% случайных джампов конечно никогда не отловить. А вот если предположить что джампы на любую величину смещения относительно заданной точки равновероятны, то можно отловить большинство случайных джампов.. Отловить в смысле обнаружить в программе, что случайный джамп имел место. Выше уже приводилось по крайней мере 2 метода как это сделать

Как правило после такого сбоя устройство перезагружается по WDT.

С чего Вы это взяли? Допустим во FLASH некоторый код изменился так, что вместо команды установки флага "Пришёл пакет извещения о пожаре" будет команды сброса этого флага. И девайс будет работать нормально просто в любом случае будет считать, что у него всё ОК и никакого пожара нет. И соответственно никакого зацикливания/зависания не произойдёт, а девайс при этом будет находиться в неисправном состоянии

Второе - система продолжает работать но часть функций отказала. Лечится перезагрузкой

Сама по себе перезагрузка, как таковая, ничего не лечит. Она просто сбрасывает MCU периферию в исходное состояние. Более того, она не позволит установить причину перезагрузки. Например если зацикливание было вызвано самопроизвольным изменением регистра UBRR из-за чего UART перестал принимать пакеты извне или случайым сбросом флага разрешения прерываний от UART, то после перезагрузки вся периферия сброситься в исходное состояние и мы не узнаем "а чё это было-то?"

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

А кто будет считать этот тайм-аут?

[defunct]

В корне не согласен с этой аксиомой(откуда Вы это взяли). 100% случайных джампов конечно никогда не отловить.

Потому что:
1. Они случайны, а это значит что можно прыгнуть из "RET" одной функции на "RET" другой.
2. Есть вероятность сбоя детектора, поясню - достаточно мощная EM помеха, способная привести к прыжку бог знает куда, также легко может нарушить содержимое памяти.

Ну и Вы сами говорите что 100% нельзя отловить, а раз 100% нельзя отловить то зачем их ловить?!

Чаще выгоднее мониторить конкретные узлы МК. И делать recovery там где это возможно, но не всегда это возможно вообще...

А вообще, советую поработать с ARM, прыжки случайные там отлавливаются самим процессором на раз аппаратурой процессора. Сильная EM помеха приводящая к случаному прыжку и Вы раньше или позже, но 100% попадете в один из трех Exception'ов DABT/PABT/UNDEFABT.

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

то после перезагрузки ...

Пардон..Пардон..Прошу прощения

Совсем упустил из вида , что Вы юзаете Меги у которых при наступлении тайм-аута WDT проц не сбрасывается, а переходит на вектор прерывания

[defunct]

С чего Вы это взяли? Допустим во FLASH некоторый код изменился так, что вместо команды установки флага

Не о том речь. Конечно сбой надо продетектить, и он продетектится в idle таск'е, если система до этого сама не прыгнет по reset вектору.
Речь о том, что до сброса мы не сможем отдетектить нарушение FLASH. Ну это просто очень накладно пересчитывать CRC флеша постоянно в процессе работы.

Сама по себе перезагрузка, как таковая, ничего не лечит.

Ну здрасти. Она переводит устройство в безопастное состояние.
Представьте, что Ваше устройство управляет котлом, и в результате сбоя может произойти взрыв. Сделав перезагрузку, мы вернемся в безопасное, 100% контроллируемое состояние.

Например если зацикливание было вызвано самопроизвольным изменением регистра UBRR из-за чего UART перестал принимать пакеты извне или случайым сбросом флага разрешения прерываний от UART, то после перезагрузки вся периферия сброситься в исходное состояние и мы не узнаем "а чё это было-то?"

Это уже не важно, т.к. боримся мы с EM помехой по условию задачи, а не со сбоем UART'a.
Ну всмысле какая нам разница что UBRR изменялся до перезагрузки, если мы его все равно перенастраиваем заново.

А кто будет считать этот тайм-аут?

idle таск'е - в той единственной задаче, которая может сбрасывать WDT.

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

Потому что:
1. Они случайны, а это значит что можно прыгнуть из "RET" одной функции на "RET" другой.

Можно.. Но так как эти реты составляют от силы 1% в программе, то это процесс маловероятный... Я ещё раз повторюсь: все 100% "прыжков" обнаружить не возможно, но 90% - вполне. А это значит, что мы увеличим надёжность нашего девайса в 10 раз: раньше было 100 необнаруживаемых сбоев, а стало 10

Есть вероятность сбоя детектора

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

Ну и Вы сами говорите что 100% нельзя отловить, а раз 100% нельзя отловить то зачем их ловить?!

Ответил выше (см. "в 10 раз").
Т.е. Вы считаете, что если я применив спец.методы построения программы сделаю так, что она будет обнаруживать всего лишь 90% случайных джампов, то Вы считаете уменьшение количества не обнаруженных сбоев в 10 раз эта такая мелочь, ради которой и не стоило утруждаться?

[defunct]

Т.е. Вы считаете, что если я применив спец.методы построения программы сделаю так, что она будет обнаруживать всего лишь 90% случайных джампов, то Вы считаете уменьшение количества не обнаруженных сбоев в 10 раз эта такая мелочь, ради которой и не стоило утруждаться?

Вообще-то да. Потому что к фатальным последствиям приведет как раз неучтенный случай из оставшихся 10%. А раз все не покрывается, то "овчинка выделки не стоит".

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

А вообще, советую поработать с ARM, прыжки случайные там отлавливаются самим процессором на раз аппаратурой процессора.

Здорово... Я бы конечно лучше бы юзал процессоры, в которых АППАРАТНО заложен контроль доступа к отдельным логическим сегментам кода.. Представляете как бы было здорово.. Разметил флешь на сегменты и потом чтобы перейти из сегмента А в сегмент В нужно записать сначала номер В в спец. регистр защиты памяти... Пусть мы скаканули из-за помехи из А в В... Но проц этот аппаратно обнаруживает путём анализа: соответствует ли содержимое регистра защиты памяти и номер сегмента , в котором мы находимся в данный момент... Хотя и в этом случае прыжки из одной части сегмента в другую часть этого же сегмента были бы не обнаруживаемымм

Ну здрасти. Она переводит устройство в безопастное состояние.

Не согласен.... Сброс может длиться 64 мС и более.. А я ручками обнаружив случайный джам через 50 мкС переведу все порты в безопасное состояние.

Дык всё же Вы какие процы используете? Вы вроде говорили, что те, у которых по таймауту WDT происходит не сброс , а прерывание

Ну всмысле какая нам разница что UBRR изменялся до перезагрузки, если мы его все равно перенастраиваем заново.

Большая... Нам нужно вести статистику сбоев... А она подразумевает классификацию сбоев... Эта статистика позволит нам потом выявить самое слабое место устройства и принять соответствующие меры

idle таск'е - в той единственной задаче, которая может сбрасывать WDT.

А поподробней... Т.е. эта задача обслуживает счётчики всех потоков и если какой-то оказывает, что наступил тайм-аут, то idle поток выполняет команду wdr и ждёт сброса? Так чтоли?

[defunct]

Здорово... Я бы конечно лучше бы юзал процессоры, в которых АППАРАТНО заложен контроль доступа к отдельным логическим сегментам кода.. Представляете как бы было здорово..

Так в чем вопрос - переходите на ARM с MMU. В старших моделях (920T и выше) мало того, что каждому килобайту памяти можно настроить параметры доступа, так еще определяется и "выровнянность" кода. А если прыгнули внутри одного блока - то DATA_ABORT обеспечен, т.к. сбой произойдет из-за искаженных данных. Но и в младших моделях некоторые прелести MMU есть, а цена такая же как и на меги.

Дык всё же Вы какие процы используете? Вы вроде говорили, что те, у которых по таймауту WDT происходит не сброс , а прерывание

разные. и те что с прерывание от WDT и те, что только со сбросом..

Большая... Нам нужно вести статистику сбоев... А она подразумевает классификацию сбоев... Эта статистика позволит нам потом выявить самое слабое место устройства и принять соответствующие меры

Может тогда проще снимать слепок всей периферии и RAM'a. Складывать куда-то во внешний eeprom. Потом вычитывать его и анализировать. Это будет много надежней, достоверней и информативней чем то, что программа сможет обнаружить сама.

А поподробней... Т.е. эта задача обслуживает счётчики всех потоков и если какой-то оказывает, что наступил тайм-аут, то idle поток выполняет команду wdr и ждёт сброса? Так чтоли?

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

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

Вообще-то да. Потому что к фатальным последствиям приведет как раз неучтенный случай из оставшихся 10%. А раз все не покрывается, то "овчинка выделки не стоит".

Странная логика... Но ведь если не применить эти методы то вероятность этих фатальных последствий возрастёт в 10 раз.... А если учесть , что у вас 10 000 девайсов работают.. Получается вообще говоря не хилая защита... Т.е. вместо 100 000 не обнаруженных сбоев у Вас будет только 10 000... А 90 000 (каждый из которых мог бы если его не обнаружить стать фатальным) Вам удасться предотвратить... И эта по Вашему ерунда?

Может тогда проще снимать слепок всей периферии и RAM'a. Складывать куда-то во внешний eeprom. Потом вычитывать его и анализировать. Это будет много надежней, достоверней и информативней чем то, что программа сможет обнаружить сама.

Да это было бы здорово, но для атмег на практике не реализуемо

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

Да...Но дело всё в том, что время между двумя запусками IDLE задачи может оказаться в десятки раз больше тайма-аута самых критических задач... Например у меня для самых критических по времени задач тайм-аут составляет 6 мС... А Время между запусами IDLE-потока колеблется от 1 до 10 Сек

[defunct]

Да это было бы здорово, но для атмег на практике не реализуемо

Почему?!
Что мешает по прерыванию WDT вычитать все регистры периферии, переинициализировать UART и выдать слепок памяти "как есть" в консоль. После чего девайс уходит на перезагрузку.

Как минимум
m88/m168/m640/1/m1280/1/ и т.п.
позволяют так сделать.

Но дело всё в том, что время между двумя запусками IDLE задачи может оказаться в десятки раз больше тайма-аута самых критических задач... Например у меня для самых критических по времени задач тайм-аут составляет 6 мС... А Время между запусами IDLE-потока колеблется от 1 до 10 Сек

Ну это уже конкретная реализация системы..
Для такой реализации можно перенести WDR в kernel-level задачу. Но идея остается неизменной - команда WDR должна быть одна на всю программу, и должна вызываться только тогда когда достоверно известно, что все задачи в порядке.

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

Почему?!
Что мешает по прерыванию WDT вычитать все регистры периферии, переинициализировать UART и выдать слепок памяти "как есть" в консоль. После чего девайс уходит на перезагрузку.

Как минимум
m88/m168/m162/m640/1/m1280/1/ и т.д.
позволяют так сделать.

Но в этом случае опять же устройство будет делать всё это само.... Я думал Вы подразумеваете "вычитывание" содержимого периферии внешним узлом например с помощью SPI.
А так как Вы говорите конечно можно сделать.. Но ведь не факт, что не покоцался сам код передатчика по UART

[defunct]

Но в этом случае опять же устройство будет делать всё это само.... Я думал Вы подразумеваете "вычитывание" содержимого периферии внешним узлом например с помощью SPI.

Нет, внешним узлом никак....

А так как Вы говорите конечно можно сделать.. Но ведь не факт, что не покоцался сам код передатчика по UART

Дык, разместите этот код в секции бутлоадера и поставьте Fuse защиты от SPM. Будет полная гарантия того, что код обработчика WDT - жив.

[Rst7]

Объясните, как-же у вас в таких корпусах от наносекундных помех ничего не сбивается? Вы экраны ставите? Или как вы этого добиваетесь?

Да нет там экранов. Просто выполнено как положено, не раз тут методики правильного проектирования обсуждали. Хотя, кое-где этими методиками пренебрегли и имели на первой итерации испытаний бледный вид и зад в мыле (потому как отправляли человека, который проводил испытания, пить кофе, а за это время костылями переделывали, потом, конечно, правили платы (как один прибор испытания прошел, до сих пор поражаюсь, там такая петля была по земле, жуть... видно было, что сейчас упадет, но асилил. Быстренько бросили гвоздь поверх и все сразу полегчало) и схемотехнику (тут обычно ничего страшного, просто там забыли суппрессор или там забыли что-то)). А с другой стороны, например, центральный прибор с основным мозгом четыре круга нарезал по нс и мкс, потому как мелочь всякая в комплекте с ним проверялась и хоть бы хны...

Только без обид. Rst7, заранее извиняюсь! Простите, что первое на ум пришло написал. А стирать жалко.

Да ладно. Не увлекайтесь только...

[galjoen]

Ну и Вы сами говорите что 100% нельзя отловить, а раз 100% нельзя отловить то зачем их ловить?!

CRC тоже 100% защиты не даёт. CRC16 не более чем в 65536 раз защищённость повышает, а CRC32 не более чем в 0x100000000 раз. Что тогда и CRC не пользоваться? Это-же не 100%!

Конечно сбой надо продетектить,

+1

Речь о том, что до сброса мы не сможем отдетектить нарушение FLASH. Ну это просто очень накладно пересчитывать CRC флеша постоянно в процессе работы.

Совершенно не накладно. В задаче с наименьшим приоритетом по 1-му слову за раз. У меня это основной цикл. У вас это idle таск. Только срабатывать это должно не сразу. А например, когда 2 раза подряд CRC не совпало.

Так в чем вопрос - переходите на ARM с MMU. В старших моделях (920T и выше) мало того, что каждому килобайту памяти можно настроить параметры доступа, так еще определяется и "выровнянность" кода. А если прыгнули внутри одного блока - то DATA_ABORT обеспечен, т.к. сбой произойдет из-за искаженных данных. Но и в младших моделях некоторые прелести MMU есть, а цена такая же как и на меги.

У ARM код из ОЗУ берётся. А в ОЗУ код гораздо больше изменениям от помехи подвержен, чем во FLASH. Хотя-бы при переписывании его туда.

[singlskv]

Странная логика... Но ведь если не применить эти методы то вероятность этих фатальных последствий возрастёт в 10 раз....

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

Не отсыпите пару кило таких помех для прикручивания к своим проектам ?
А то, все как-то больше, непослушные помехи попадаються, так и норовят прыгнуть
куда-нить не туда...

[defunct]

Совершенно не накладно. В задаче с наименьшим приоритетом по 1-му слову за раз. У меня это основной цикл. У вас это idle таск. Только срабатывать это должно не сразу. А например, когда 2 раза подряд CRC не совпало.

Это вариант. Только я считаю, что это лишнее..
Ну просто не будет программа работать нормально если часть флеша слетит по причине прыжка на erase sequence в бутлоадере, не вернемся мы оттуда в ОС... Следовательно тут как раз WDT помощник.
Ну а если предположить, что мы все-таки вернулись после erase sequence в ОС и продетектили нарушение флеш в основной программе, что дальше? Выход ведь тот же самый - сброс и запуск бутлоадера.

У ARM код из ОЗУ берётся. А в ОЗУ код гораздо больше изменениям от помехи подвержен, чем во FLASH. Хотя-бы при переписывании его туда.

У мелких АРМов (конкурентов мег) есть FLASH. Хотите размещайте во флеш, не хотите - копируйте и запускайте в RAM.

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

У ARM код из ОЗУ берётся.

Ээээ...Тогда они однозначно менее надёжны, поскольку ОЗУ попортить помехе гораздо легче чем ПЗУ

И прыгают они у Вас исключительно на код, а на данные размещенные во флеш
видимо никогда не прыгают

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

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

+

до сих пор поражаюсь, там такая петля была по земле, жуть...

Странно.. Я читал совершенно другие "методики правильного проектирования". Что наооборот землю надо пускать кольцом по краю платы

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

Не секрет, что стоимость простых MCU упала до стоимости одного транзистора. Т.е. менее 1$.
Для разработчиков открылась возможность использования в ОДНОМ устройстве сразу несколько MCU.
Использовали ли Вы в своих разработках многопроцессорные конфигурации. Но не с целью добавить функциональность, а конкретно с целью увеличения надёжности работы устройства (горячее резервирование, мажоритарное голосование и т.д.)

Интересует что конкретно вы реализовывали в многопроцессорных конфигурациях и за счёт чего увеличивали надёжность.. Интересуют использованные вами принципы и нюансы реализации

[zltigo]

Не секрет...

Для затравки 5 эпизод. http://www.iosifk.narod.ru/engineer_storys.htm

Moderator:
Перенес эту тему в существующую ветку. Если получится хоть сколь-нибудь конструктивное обсуждение - обещаю выделить в отдельную тему.

[Rst7]

Странно.. Я читал совершенно другие "методики правильного проектирования". Что наооборот землю надо пускать кольцом по краю платы

Я немного не так выразился, видимо. Там просто минус питания проца был присоединен в такую точку, на которой потенциал сильно подпрыгивал при попадании на внешний интерфейс испытательного импульса (или непосредственно в минус этого интерфейса, соединенного с землей, или в плюс, который соединен с минусом через суппрессор). Надежно было убрано организацией пути тока мимо этого отростка. Так что там не совсем петля была...

[singlskv]

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

Ой..., а Вы не просветите нас про Ваш дезактивированный формат ? или еще
не придумали как это должно выглядеть...
Ну и как-то вопрос про 32бит команды был обойден, не нравятся неудобные вопросы ?

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

Ой...

Да ничо, ничо

а Вы не просветите нас про Ваш дезактивированный формат ? или еще
не придумали как это должно выглядеть...

Почему же...Придумал.. И давно уже юзаю...У меня данные храняться в команде CPI Rd , K.
Как Вы, конечно же знаете, код этой команды 0011KKKK ddddKKKK. Отсюда 12 из 16 бит ячейки флэшь можно заюзать под данные. Т.е. 25% объёма флешь мы теряем в случае такого способа хранения данных.. Но зато !!!! Если в результате случайного джампа проц попадёт на область данных, то он просто выполнить цепочку команд CPI Rd , K а в конце области данных у меня стоит джамп JMP CRASH

Сообщение отредактировал Дон Амброзио - Feb 14 2008, 18:56

[singlskv]

Почему же...Придумал.. И давно уже юзаю...У меня данные храняться в команде CPI Rd , K.
Как Вы, конечно же знаете, код этой команды 0011KKKK ddddKKKK. Отсюда 12 из 16 бит ячейки флэшь можно заюзать под данные. Т.е. 25% объёма флешь мы теряем в случае такого способа хранения данных.. Но зато !!!! Если в результате случайного джампа проц попадёт на область данных, то он просто выполнить цепочку команд CPI Rd , K а в конце области данных у меня стоит джамп JMP CRASH

Хотелось бы увидеть реальный пример хранения ну например таблиц CRC16 modbus в
"дезактевированном" состоянии....

Нет в ATmega-х таких команд

Ээээ..., Вы правда знаете все команды ATmega ?
LDS,STS это какие-то другие команды ? не 32 бит ?
Ну уж просветите, наш Гуру...