реклама на сайте
подробности

 
 
2 страниц V  < 1 2  
Reply to this topicStart new topic
> Какая вероятность порчи данных в разных областях памяти AVR?
ILYAUL
сообщение Sep 16 2011, 10:04
Сообщение #16


Профессионал
*****

Группа: Свой
Сообщений: 1 940
Регистрация: 16-12-07
Из: Москва
Пользователь №: 33 339



QUOTE (Laksus @ Sep 16 2011, 11:48) *
Возвращаясь к первому вопросу - какая вероятность порчи данных в ram, eeprom, flash?

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


--------------------
Закон Мерфи:

Чем тщательнее составлен проект, тем больше неразбериха, если что-то пошло не так
Go to the top of the page
 
+Quote Post
Alfa
сообщение Sep 16 2011, 10:55
Сообщение #17


Участник
*

Группа: Участник
Сообщений: 52
Регистрация: 9-02-06
Из: Челябинск
Пользователь №: 14 160



Цитата(Laksus @ Sep 16 2011, 13:48) *
Возвращаясь к первому вопросу - какая вероятность порчи данных в ram, eeprom, flash?
И вытекающий из первого - нужно ли принимать меры по проверки целостности данных и какие?


У меня исторически сложилось что при запуске проверяется контрольная сумма и памяти программ и памяти данных.
Если проблемы - индицируем пользователю.
Прошивка может обновляться, поэтому чтобы быть уверенным что все залилось корректно - проверяю CRC flash.
Параметры в eeprom влияют на алгоритмы работы прибора. Параметры также могут меняться юзером. Потому проверяю CRC eeprom. Если есть возможность храню две копии параметров. Одна сбойнет - читаем другую и восстанавливаем порченную....

Насчет контроля ОЗУ. никогда не применял. ИМХО этот изврат может понадобиться крайне редко. например если рядом включаются- выключаются многокиловатные движки или взрываются атомные бомбы...


как то так
Go to the top of the page
 
+Quote Post
defunct
сообщение Sep 18 2011, 21:23
Сообщение #18


кекс
******

Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326



Цитата(ArtemKAD @ Sep 14 2011, 16:43) *
Правильно - регулярное обновление. Как вариант - выбрать некоторое событие

Регулярное обновление чего? данных в RAM? или данных в EEPROM?

Мне все же схема автора кажется куда более правильной, единственное нужно помочь ему подправить ее напильником:

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

энергонезависимая память здесь любое из:
внутренний/внешний eeprom/флеш, SD карточка, MMC, и т.д. и т.п.

Цитата(Laksus @ Sep 16 2011, 10:48) *
Возвращаясь к первому вопросу - какая вероятность порчи данных в ram, eeprom, flash?
И вытекающий из первого - нужно ли принимать меры по проверки целостности данных и какие?

Могу дать свои цифры для таких начальных условий: Планируется эксплуатировать устройство 1 год, включать-отключать раз в неделю, BOD выключен, нет внешнего супервизора питания, в программе есть функции записи флеш (команда SPM):
вероятность "порчи" флеш - 100%.
такая же самая вероятность и "порчи" eeprom, при тех же начальных условиях. Всё это из-за 100% "порчи" RAM при выходе питания за допустимые пределы.

Включение BOD - практически полностью убирает возможность искажения RAM по вине железа. Но если в коде будут вызовы SPM, тогда даже с включенным BOD'ом вероятность что-то угробить во флеш/eeprom будет очень высока. Ключевой момент - запись в EEPROM и FLASH - длительная операция, достаточно рубануть питание в момент записи, для того чтобы появилась "порча" данных (данные записались/стерлись не польностью). Делайте выводы.
Go to the top of the page
 
+Quote Post
thinkerreed
сообщение Sep 19 2011, 09:45
Сообщение #19





Группа: Новичок
Сообщений: 8
Регистрация: 11-09-09
Пользователь №: 52 305



Была недавно проблема с eeprom в серии девайсов, где на атмеге до кучи сделаны и часы. Научить потребителей обращаться с платами аккуратно - это нечто нереальное, а включать BOD - тоже не вариант, потребление от батарейки возрастает почти на порядок. Несколько раз из эксплуатации возвращались платы с полностью занулённой eeprom, хз как такое получается (ИМХО очень маловероятно). В итоге пришли к тому, чтобы критически важные данные (такие как серийник) писать во flash и устанавливать lock, после этого безобразие прекратилось.
Go to the top of the page
 
+Quote Post
Maik-vs
сообщение Sep 19 2011, 12:01
Сообщение #20


Местный
***

Группа: Участник
Сообщений: 246
Регистрация: 4-12-06
Пользователь №: 23 101



В EEPROMе пусть хранится набор данных с возможностью проверки (CRC, две копии и т.д.) Читаем из EEPROM в RAM когда юзер начал пользоваться прибором, или там вызвал меню. Если такого события нет, то раз в десятки минут - часы. Если данные повреждены, восстанавливаем их из FLASH, где лежит дефолтный набор. Настройки обнуляются - сбой серьёзный, но не смертельный.
Если основная программа содержит SPM, проверяем её CRC при включении питания. Не сходится CRC - уходим на бут-лоадер, если он есть, и бесконечно мигаем индикаторами.
У меня бывало, слетали и флеш и епром, при больших неприятностях по питанию - например, резко клинит большой коллекторный движок, или лопается мощная галогеновая лампа. Тогда происходят разные электромагнитные процессы, горят предохранители, срабатывают защиты, ну вылетал флеш пару раз...

Сообщение отредактировал Maik-vs - Sep 19 2011, 12:02
Go to the top of the page
 
+Quote Post
ArtemKAD
сообщение Sep 19 2011, 15:35
Сообщение #21


Профессионал
*****

Группа: Свой
Сообщений: 1 508
Регистрация: 26-06-06
Из: Киев
Пользователь №: 18 364



Цитата
а включать BOD - тоже не вариант, потребление от батарейки возрастает почти на порядок

В новых AVR (PA) используйте коммутируемый BOD. Или прежде чем писать EEPROM проверяйте АЦП хватит ли питания для записи.
Go to the top of the page
 
+Quote Post

2 страниц V  < 1 2
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 26th June 2025 - 04:29
Рейтинг@Mail.ru


Страница сгенерированна за 0.01401 секунд с 7
ELECTRONIX ©2004-2016