[gerber 8]

Почему же не пойти очевидным путём - применить при записи в FRAM помехоустойчивое кодирование с какой-нибудь трёхкратной избыточностью ? Наподобие того, что используется при записи компакт-дисков. Рида-Соломона какого-нибудь ?

[Plain 223]

Делать хитрый алгоритм

Ну да, чтобы заменить им пару соплей и резисторов, с гордостью отвергнутых чуть выше:

 

2Plain :bb-offtopic:

[ReAl 0]

Продавать. слишком дорогая партия чтоб перевыпускать и слишком длинный цикл производства. Поэтому проблему будем решать и решать ТОЛЬКО программно.

А извещение с «имеющийся задел доработать» не пройдёт?

И таки аккуртано на плату пристроить пару деталюшек, проводочки да детальки прихватить эпоксидкой...

 

У меня «когда-то давно» в FM24C16 (других ещё не было) несколько копий просто не лезло.

Контрольные суммы были, но, как оказалось, только для того, чтобы убедиться — при проверке питания на входе стабилизатора (о чём тут неоднократно говорилось) перед любым обращением к FRAM (и к прочим внешним) за несколько тысяч устройство-лет эксплуатации в условиях непредсказуемо пропадающего питания сбои FRAM бывали (и то не всегда) только в устройствах, которые во включенном состоянии (а они были всегда во включенном) заливали пепси-колой. Кофе-чай-газировка не страшно :-).

[juvf 17]

2gerber

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

 

Есть же всякие алгоритмы с избыточным кодированием с возможностью восстановления.... можно свое что-то написать. но я думаю что велосипед уже изобретён.... Кто может ещё, что-то посоветовать, какие нибудь алгоритмы восстановления?

 

2Plain

Не совсем понятно что и кому вы хотите показать? Несостоятельность моего девайса, я не собираюсь это оспаривать, или свою несостоятельность как инженера? Решить проблему перезапуском плат - любой сможет... любой школьник встретив такую трудность скажет - "перезапуск плат". Была бы возможность перезапуска плат - я бы тут даже не постил тему. Перезапустил бы молча. Но зачем компании нужен такой инженер, который не может решить "невыполнимые" задачи. Архимед один выполнил задачу которую не смогло решить 100500 рабочих(солдат) - столкнуть корабль. Придёте вы на собеседование к работодателю.... дадут вам тест "программно сделать безопасное чтение/запись фрамки без контроля питания". Что вы им скажете? "Ну да, чтобы заменить им пару соплей и резисторов, с гордостью отвергнутых чуть выше:". А другой кандидат применит Рида-Соломона и/или разберётся со строением фрамки и предложит живучий алгоритм сэкономив тем самым компании 1000нефти.

 

Понятно, что всех как магнитом тянет на аппаратное решение проблемы. Но аппаратно не возможно. Я могу обосновать почему невозможно, на несколько страниц расписать... но зачем? Скажу просто:

 

Вводная: (2Plain считай что это абстрактная задача, допустим математическая олимпиада)

программно сделать безопасное чтение/запись фрамки без контроля питания и без аппаратного вмешательства

 

ps

2Plain возможно вы правы на счет невозможности. и у вас есть такой опыт.... т.е. вы пробовали применить разное избыточное кодирование с восстановлением и применительно к фрамке это не работает... т.к. во время окончания последнего 8-го бита данных в фрам открывается такой-то транзистор.... происходит выборка строки .... регенерация адреса .... бла бла бла .... В результате чего портится то-то и то-то.... и восстановить такую информацию математически не представляется возможности.... Самую низкую вероятность сбоя показал восстановительный код Иванова-Сидорова, но при прогоне в климатической камере при t<-10°C и при t>50°C частота возникновения ошибки увеличиваются и вероятность сбоя возрастает до такой-то величины. .....

Конечно если предоставить компании подобные доводы и/или результаты исследования, то будут искаться другие пути решения проблемы. Но пока тупо - "Так сделать невозможно" или "Если платы не работают, они не сделаны. Можно повторять это бесконечное число раз, ничего не изменится." выглядит как маза.

Один инженер обосновал мне теоретически, на низком уровне (строение фрам), что црц+дублирование не поможет. Но с др. стороны практик

Я пишу две копии, у каждой crc16. Случаев одновременного сбоя обеих копий не замечено.

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

Изменено 4 июня, 2012 пользователем juvf

[Plain 223]

Ваши эмоции спишу на утро понедельника.

 

"Фобос-Грунт" утоп в т.ч. по причине такой же маниловщины менеджеров.

 

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

 

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

 

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

[maksimp 0]

считай что это абстрактная задача, допустим математическая олимпиада)

программно сделать безопасное чтение/запись фрамки без контроля питания и без аппаратного вмешательства

Этого нельзя.

 

Доказательство примерно:

Допустим питание сбилось и есть испорченная ячейка.

При каждом следующем включении питания и запуске алгоритма, он пытается сверить данные и исправить повреждения. Для этого он сначала читает сколько-то ячеек, проводит с ними вычисления, и затем записывает исправленное значение в испорченную ячейку. Среди прочтённых (до выполнения первой записи исправленного значения) ячеек сколько-то верных и сколько-то уже испорченных. Если все прочтённые ячейки испорчены то записать что-либо верное он уже не сможет. Значит надежда есть только если среди прочтённых значений есть верные. Но тогда дёрнем питание во время чтения какой-либо из верных ячеек. В результате испортилась ещё одна ячейка, а восстановить что-либо алгоритм не успел - всё это происходит до того как алгоритм собирается записывать что-либо. Так одну за одной испортим все ячейки.

 

[juvf 17]

2 maksimp

Теоретически вы правы. Сейчас я сделал единождое чтение фрамки при вкл. питания в озу и работа с данными из озу. Это должно снизить вероятность потери данных. Планируется эксплуатация 24 часа 15 лет. Один раз за весь срок службы включили - одна операция чтения. Но я понимаю, что теоретически лошадь, а практически упала. Добавлю копию+црц, добавлю восстановительный код с большим избытком. Думаю, что вероятность выключения питания сразу после включения, да многократно, да с порчей каждый раз новых ячеек теоретически равна..... это всё похоже на теорию о бесконечных обезьянах.

 

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

 

Всем спасибо

Изменено 4 июня, 2012 пользователем juvf

[barabek 0]

2 maksimp

Теоретически вы правы. Сейчас я сделал единождое чтение фрамки при вкл. питания в озу и работа с данными из озу. Это должно снизить вероятность потери данных. Планируется эксплуатация 24 часа 15 лет. Один раз за весь срок службы включили - одна операция чтения. Но я понимаю, что теоретически лошадь, а практически упала. Добавлю копию+црц, добавлю восстановительный код с большим избытком. Думаю, что вероятность выключения питания сразу после включения, да многократно, да с порчей каждый раз новых ячеек теоретически равна..... это всё похоже на теорию о бесконечных обезьянах.

 

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

 

Всем спасибо

Честно говоря не знал, что у FRAM разрушающее чтение. Сам использовал много раз и никогда проблем не было. Может повезло или не заметили. Есть приборы, порядка сотени-двух штук. В них запись текущего положения идет 10 раз в секунду. В этой же памяти хранится конфигурация, при сбое которой прибор перестанет запускаться. Приборы работают 24 часа. Еще, тьфу-тьфу-тьфу, не одного сбоя. А у Вас вот как. Самому лень, но может Вы, раз у горит проведете более качественные тесты. Я бы делал так. На тестовой плате сделать возможность отключать питание с FRAM. Написать прогу, работающую по такому алгоритму. Запись каждый раз случайных значений в память, дабы не было корреляции между ячейками. Затем чтение и во время чтения выключение питания, например транзисторным ключем, а лучше реле, чтобы была и случайность времени отключения и дребезг. Потом включение и повторное считывание. Сравнивая с записанным можно определить, во-первых, вероятность отключения, во-вторых, если сбоев будет много - зависимость между сбойными ячейками. И так по кругу. Даже по одной секунде на цикл за сутки уже получается 86400 опытов. Довольно много. Для чего нужно "во-первых" понятно, а "во-вторых" может повысить восстанавливающие способности кода. Допустим, выяснится, что между собой зависят биты (а не байты!) в ячейка, скажем 0-31-63- ... и портится только в одному ряду/колонке, а не по нескольким, то тогда можно сделать Рида-Соломона с соответствующим перемежением бит. Что повышает восстанавливающую способность в 8 раз! Т.е. не, скажем, 4 символа, а 4*8=32 бита. Если у Вас вдруг хватит сил это проделать отпишитесь, пожалуйста, сюда.

ОФФ. А советы "Кац предлагает сдаться, предлагает сдаться" (цэ) не слушайте. Мне понятно Ваше раздражение по этому поводу.

[maksimp 0]

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

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

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

Тогда порядок действий может быть такой:

- Увеличиваем потребление.

- Проверяем питание с помощью тестовых ячеек FRAM.

- Снижаем потребление.

- Читаеи или пишем в FRAM полезные данные.

И нужно конечно выяснить, какие ещё ячейки FRAM портятся заодно с той при обращении к которой пропало питание.

[xemul 0]

... то измерить напряжение питания можно с помощью самой FRAM.

Измерение по определению - сравнение с эталоном. Какой может быть эталон у микросхемы при напряжении питания ниже оговоренного в ДШ?

Производитель в ДШ на FM25CL64B (вероятно, не только у ТС приключались такие траблы) добавил раздел "Power Cycle Timing", и при соблюдении его требований описанные проблемы наблюдаться не должны. (а тот, кому ДШ не указ - ССЗБ)

[zombi 0]

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

А в Ваших приборах есть хоть какой то супервизор питания?

 

Фрамкой управляет синтезированый NIOS в ПЛИС Cyclon III. В ней нет BOD (((.

А может проблема вовсе не в фраме, а в напрочь отсутствующем хоть каком либо BOD в изделии?

И при понижении питания Cyclon III "летает" где хочет и творит что угодно с фрам.

[barabek 0]

А в Ваших приборах есть хоть какой то супервизор питания?

Нет, и даже в контроллере оказывается Vdd-монитор не включен. Нужно будет включит на всякий :).

 

 

[juvf 17]

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

однако целый ниокр. время выкраю, проведу такое исследование.

Есть приборы, порядка сотени-двух штук.

а какая конкретно фрам стоит?

 

И при понижении питания Cyclon III "летает" где хочет и творит что угодно с фрам.

Может быть.... однако если идет команда чтения..... ну улетел ниос.... Это как он должен улелеть? пошла команда на чтение.... ниос полетел и вместо чтения передал команду Write Enable Latch, потом снял cs, потом выставил cs и передал команду записи и записал кудато мусор. Как-то маловероятно что с Write Enable Latch ниос улетит так, что попортит фрам. вся конфигурация плис хранится в другой памяти, в epcs. Если бы ниос так "летал" то он бы мог и епцс попортить. но случаев разрушения данных в епцс во время чтения замеченно не было и ни от кого ни разу не слышал о таком. думаю что это всётаки фрам виноватая.

Буду тест проводить..... процесор не будет выключаться, чтоб не улетал, только фрам буду отрубать.

 

то измерить напряжение питания можно с помощью самой FRAM.

мысль не понял.

 

Изменено 5 июня, 2012 пользователем juvf

[barabek 0]

а какая конкретно фрам стоит?

FM24C64

 

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

Буду тест проводить..... процесор не будет выключаться, чтоб не улетал, только фрам буду отрубать.

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

 

 

А в epcs запись подубовей, времени больше требуется. Может по этому. Да и запись там повышенным напряжением.

 

 

 

[zombi 0]

Если бы ниос так "летал" то он бы мог и епцс попортить. но случаев разрушения данных в епцс во время чтения замеченно не было и ни от кого ни разу не слышал о таком. думаю что это всётаки фрам виноватая.

Не работал с цыклонами. Но у них есть "Power On Reset Monitor" может это и есть некий BOD?

 

ЗЫ. да точно, "летать" не может

The POR circuit of the Cyclone III device monitors the VCCINT, VCCIO