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

 
 
> работа с flash под CodeVision
Alex_TAV
сообщение Nov 5 2008, 05:29
Сообщение #1


Частый гость
**

Группа: Свой
Сообщений: 145
Регистрация: 12-01-07
Из: Россия, г. Омск
Пользователь №: 24 357



Так как хранить данные в EEPROM у AVR становится все ненадежней, есть идея располагать константы во flash - благо необходимость в их изменении будет ну максимум раз в год, а то и реже. Так вот с чтением из flash проблем нет, а есть ли функции в CodeVision для записи во flash? А то стандартно по страницам не очень удобно.
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
Непомнящий Евген...
сообщение Nov 5 2008, 05:47
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153



Цитата(Alex_TAV @ Nov 5 2008, 09:29) *
Так как хранить данные в EEPROM у AVR становится все ненадежней

А откуда такая информация?
Go to the top of the page
 
+Quote Post
_Pasha
сообщение Nov 5 2008, 07:19
Сообщение #3


;
******

Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509



Цитата(Непомнящий Евгений @ Nov 5 2008, 08:47) *
А откуда такая информация?


Я тоже хочу спросить: откуда ?
Сегодня ночью ездил на объект - слетел 16-битный параметр в еепроме в моем приборе. СтоИт мега 48.
БОД итд. В общем - полгода работал, а тут - нате... Других подобных историй не было.
Go to the top of the page
 
+Quote Post
gormih
сообщение Nov 5 2008, 13:18
Сообщение #4


nofb
***

Группа: Свой
Сообщений: 430
Регистрация: 18-05-06
Из: Москва, Зеленоград
Пользователь №: 17 218



Цитата(_Pasha @ Nov 5 2008, 10:19) *
Сегодня ночью ездил на объект - слетел 16-битный параметр в еепроме в моем приборе. СтоИт мега 48.
БОД итд. В общем - полгода работал, а тут - нате... Других подобных историй не было.

Товарищ по несчастью smile.gif
К резервному дублированию данных и к хранению во флэш приходишь уже после таких инцидентов sad.gif

Цитата(haker_fox @ Nov 5 2008, 11:49) *
Так может быть причина "слета" не в железе, а в программе? Я тоже уверен, что с EEPROM у AVR дела давно уже наладились. Хотя никто для подстраховки не помешает применять внешнюю с I2C, но это уже не то. Да и та сбойнуть может, кого винить тогда? smile.gif

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


--------------------
Это не то что вы подумали ...

Go to the top of the page
 
+Quote Post
defunct
сообщение Nov 6 2008, 07:17
Сообщение #5


кекс
******

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



Цитата(gormih @ Nov 5 2008, 15:18) *
Не бывает такого, что программа работает полгода без сбоев, потом резко у нее портится настроение и дает сбой. Если конечно сам такого исхода не заложишь... Это чисто железная проблема. И случаи не еденичные.

Бывает еще как.
Ошибка в логике обработки переходного процесса... И допустить такую ошибку ой как легко, т.к. условия ее возникновения порой нельзя даже представить.
Суть даже не в eeprom'е, у меня портился NVRAM контекст (2 копии защищенных CRC16), причем как выяснилось портил я его сам при определенных условиях. А условия вот такие:

1. МК всегда безусловно пишет две копии контекста, в одном и том же порядке (вначале первую копию, потом вторую), по одним и тем же адресам NVRAM'а.
2. Питание проседает до 4.1, затем нарастает до 4.3 и так несколько раз подряд, а потом падает ниже 4.0. (BOD на 4.0).
3. Когда питание падает ниже 4.125V NVRAM уходит в себя (чтобы спасти RTC), тупо отрубается от I2C шины и ему пофиг идет транзакция или не идет в данный момент.

К чему это приводило:
Пусть МК успешно записал первую копию контекста, после чего в процессе записи второй копии напряжение проседает до 4.1V - МК естессно отваливает с ошибкой I2C timeout, пытается достучаться еще несколько раз, а девайса то просто нет на шине. Так портится вторая копия контекста в NVRAM'е.
Через некоторое время (через 1 сек) МК пробует сохранить обновленный контекст - питание к тому времени восстанавливается и NVRAM разлочен. МК начинает писать первую копию, в процессе записи питание падает ниже 4.0V - срабатывает BOD - и писец - обе копии контекста потеряны. Кто виноватъ? HW?
И сколько бы копий ни было вероятность потерять все копии остается, т.е. это БАГ ЛОГИКИ.

Спрашивается кто мешал прочитать контексты перед записью, кто мешал проверить какой из них жив, а какой - нет, и обновить только битую копию. Кто мешал промониторить питание, и даже не соваться к NVRAM'у когда ясно что он вот-вот отключится?
Go to the top of the page
 
+Quote Post



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

 


RSS Текстовая версия Сейчас: 23rd August 2025 - 15:02
Рейтинг@Mail.ru


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