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

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


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



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


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


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


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


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


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





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


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

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

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

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

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

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

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

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

Вот.

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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



Принимается

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

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


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

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




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


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

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

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

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



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


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


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