Не нашел лучшего раздела в это форуме

Разработан девайс с фрамкой FM25CL64. Фрам воткнули как энергонезависимую память для конфигурационных параметров, серийного номера и т.п. На практике оказалось, что если снять питание с фрамки во время операции чтение/запись, то в ней портятся данные. Как программно решить эту проблему?
На достоверность информации можно в фраме хранить crc. Но допустим данные недостоверны - и что? К их восстановить? Есть мысль хранить данные+црц и копию данных+црц. но где-то в инете натыкался на описание такого сбоя... в результате чего допустим 4-ый байт в каждом банке был битый. получается что если испортятся данные, то и копия тоже может испортится. Кто-нибудь решал подобную проблему программно и как?

Что в Вашем девайсе пишет/читает фрам?

Т.е. питание у них разное и можно отключить питание только у фрам?

Запись во FRAM ничем не отличается (кроме скорости) от записи в EEPROM/flash. Чтение из FRAM ничем не отличается от записи в неё же.
Поэтому используются те же способы обеспечения целостности чтения/записи, что и для EEPROM/flash.
Н-р, монитор входного напряжения стабилизатора и ёмкость на его (стабилизатора) выходе, достаточная для завершения чтения/записи.
Если же только программно ... ФС с журналированием подойдёт?

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

Операции чтение/запись у FRAM нет. Есть отдельно чтение, есть отдельно запись. Причём, запись с явным разрешением (перед каждой операцией записи) отдельной командой.
Т.е., если при чтении снять питание в середине передачи например адреса - портятся данные во многих ячейках?
А Вы выжидаете время после подачи питания на микросхему памяти перед тем, как начинать читать данные (hint: читать даташит внимательно)?
brown out detecor у микропроцессора есть?

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

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


ну то это понятно, просто сократил, читайте - "Во время отдельной операции записи с явным разрешением и во время отдельной операции чтения".

Я сейчас пока так и сделал. надеюсь что обе копии не попортятся.

Вот, нашел где я это видел


это я и хотел сказать. А что за восстанавливающая запись?

У Вас строго 3.3 должно быть. Имеется?

моя микросхема FM25CL64. питание по даташиту Voltage Operation 2.7-3.65V. я её питаю 3.3. Смотрю 3-ю страницу:

Прям как говорил sgs. У него микросхема очевидно FM25C160 и питается от 5 В.

Длительность циклов запись/чтение у FRAM десятки наносекунд. Это еще нужно очень постаратся за это время снять питание. Скорее всего при снятии питания прцессор улетает куда нибудь не туда. Я в своих схемах применял супервизор по питанию и его сигналом блокировал сигнал CS на память.

...Длительность циклов запись/чтение у FRAM десятки наносекунд.
И где это вы такое прочитали?

.

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

да и действительно, от куда десятки нс?

Посмотрите параметр tD минимум 60ns между последовательными обращениями.
Я лично работал с FRAM c паралельным интерфейсом и их параметры практически совпадают со статической памятью SRAM с временем выборки 50-120ns


А конденсатор по питанию у вас стоит. И сколько времени он разряжается пока питание упадет на 10%. А если вы не позаботитесь чтобы процессор после снижения питания не начал писать что попало куда попало то он и флеш может потереть.

можете попробовать в любом сочетании:
1. Уменьшить частоту общения с FRAM насколько это возможно (обращаться на к ней, а к однажды считанной и хранящейся в RAM копии)
2. Исключить общение с FRAM во время переходных процессов (сразу после включения, после переключения мощного потребителя, при резком зафиксированном падении измеряемых величин...)
3. Использовать избыточное кодирование для восстановления данных
4. Использовать CRC для определения валидности пакета хранящихся данных.
5. иметь дубль хранимых данных на случай битого основного пакета.

У меня была одна конструкция на RAM с аккумулятором (тогда DataFlash еще не было), там годами по кругу данные записывались, CRC16+номер блока хватало для корректной валидизации блоков длиной 256 байт.
В другой конструкции (NANDFlash) применял избыточное кодирование плюс CRC - за несколько месяцев активных испытаний не было ни одного случая битого блока, а до применения избыточного кодирования это фиксировалось (благодаря CRC)

Вот это да!!! Не знал об этом.
И если это имеет место быть и для мс FM25CL64B и она также ведёт себя при питании ниже 2.7B то ни какие програмные способы не помогут.

Что-то не нашёл у FM25CL64 таких ограничений.


Аппаратные должны помочь. Включённый BOD, измерение напряжения питания схемы с запретом работы при просадке ниже допустимого и т.п.
Думаю что FRAM абсолютно (на 99,9999%) надёжна и не слетает если всё сделано правильно.
Или нет?

TC спрашивает именно о програмных.

Ну, включение BOD задаётся программатором, хотя и аппаратная штука.
А вот измерять питание - тут может потребоваться коррекция и платы и программы (запуск-обработка АЦП или компаратора).

Какой BOD и где ? Во 2-м сообщении я спрашивал TC об этом, но досих пор это остаётся загадкой.

Где удобно будет: можно встроенный, можно внешний.
Была у меня как-то давно такая же проблема: сделали девайс, настройки хранились в FRAM и слетали через какай месяц-другой. Не помню был ли в том проце BOD (SX-52 использовался). Решили проблему так: поставили внешний супервизор - он вроде и BOD и WDT одновременно. Сбои прекратились.

Цитата(juvf @ May 31 2012, 05:36)

...Аппаратную часть ни кто переделывать не будет....

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

Где был ваш вопрос про BOD? Сорри, но я не понял второго сообщения

Что значит "что"? Я же в вопросе сказал "для конфигурационных параметров, серийного номера и т.п.". Или "что" имеется в виду какой процессор управляет записью? ПЛИС(цыклон)+НИОС.
Питание одно. Отключить не возможно.

2Ruslan1
1 проблему не решает. 2 - нет возможности, 3,4,5 - тут можно что-то сделать, но если будет портится несколько ячеек в фрамке случайно разбросанных, то и это не поможет.

см сообщение 9, или/и даташит page 3.

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

если знать точное поведение фрамки при пропадании питания и структуру то можно программно решить проблему. например можно хранить 100 байт. Разбить их на 4 по 25 байт и хранить в начале каждого банка 25 байт. копию хранить в каждом банке по адресам 26-50. Если потрётся 12-ый байт в каждом банке, то попортится только одна копия. Вот только как узнать структуру фрамки? Как узнать что там происходит со строками регенерации и что будет портится?

ps. Думаю о будущем.... О будущих разработках плат.... Во первых есть мысли сделать счетчик наработки. Для этого нужно писать в энергонезависимую память что-то, причем довольно часто, например раз в минуту. Что использовать в дальнейших разработках в качестве энергонезависимой памяти чтоб не было таких проблем?
Во вторых контроль питания..... я плохо представляю как его организовать с плис..... в неё приходит 5 питаний. на плату приходит +24 и куча источников из них получает разные питания...... можно супервизор поставить на сырое питание..... но, в принципе, допустимо питать плату от +15 в. при +24 плата жрёт 1 А, при 15 будет ещё больше. поставить супервизор на +12.... это уже на +12 потребление будет 2 А. Ахтунг.... если пропадет питание, то сколько у меня будет времени? Всего-ничего. Ставить какие-нибудь мега-конденсаторы..... ионисторы.... тоже не есть гуд.
Или вообще вместо фрам поставить какойнить pic или attiny со встроенной епром и BOD.... контролировать только +3,3.
???

Может есть память которая не страдает такими болезнями? Например альтеровская EPCS. по крайней мере при чтении точно ни чего не портится.

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


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

2Plain

Ну да, я спрашивал именно об этом.
Т.е. ЧЕМ читаете/пишите фрам а вопрос есть ли у этого ЧЕГОТО аппаратный BOD был бы следующим.
Ясно.


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


1.Внешний супервизор питания.
2.Чип в котором запись/чтение 1-го байта не приводит к порче других байт.

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

Вот и я о том же. См. #16.
А с нынешней то партией плат что планируете делать?

Продавать. слишком дорогая партия чтоб перевыпускать и слишком длинный цикл производства. Поэтому проблему будем решать и решать ТОЛЬКО программно. Делать хитрый алгоритм на фрам.... или если найдем аналог пин2пин..... хотя это тянет за собой исправление в конструкторской документации, в покупных ведомостях и т.п. ..... а это ещё сложнее.... или можно попробовать использовать EPCS, она на плате есть, или вплоть до того, что откажемся от хранения данных во фраме. Но платы должны работать без сбоев.


И всё таки, по энергонезависимой, памяти кто-нибудь может сказать: "Используй чипы памяти ФТМ*56ххх5, с ними таких проблем не будет"

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

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

А извещение с «имеющийся задел доработать» не пройдёт?
И таки аккуртано на плату пристроить пару деталюшек, проводочки да детальки прихватить эпоксидкой...

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

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

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

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

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

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

ps
2Plain возможно вы правы на счет невозможности. и у вас есть такой опыт.... т.е. вы пробовали применить разное избыточное кодирование с восстановлением и применительно к фрамке это не работает... т.к. во время окончания последнего 8-го бита данных в фрам открывается такой-то транзистор.... происходит выборка строки .... регенерация адреса .... бла бла бла .... В результате чего портится то-то и то-то.... и восстановить такую информацию математически не представляется возможности.... Самую низкую вероятность сбоя показал восстановительный код Иванова-Сидорова, но при прогоне в климатической камере при t<-10°C и при t>50°C частота возникновения ошибки увеличиваются и вероятность сбоя возрастает до такой-то величины. .....
Конечно если предоставить компании подобные доводы и/или результаты исследования, то будут искаться другие пути решения проблемы. Но пока тупо - "Так сделать невозможно" или "Если платы не работают, они не сделаны. Можно повторять это бесконечное число раз, ничего не изменится." выглядит как маза.
Один инженер обосновал мне теоретически, на низком уровне (строение фрам), что црц+дублирование не поможет. Но с др. стороны практик
У меня данных немного, 100 байт, две копии влезут в один банк и возможно таких проблем действительно не будет.

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

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

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

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

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

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

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

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

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

Всем спасибо

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

Если сам контроллер не может измерить напряжение питания, то измерить напряжение питания можно с помощью самой FRAM. Выделить для этой цели несколько ячеек, записывать в них разные значения и сравнивать - если совпало то напряжение достаточно. Но питание может пропасть сразу после такого измерения, или напряжение может оказаться на грани, достаточно для одних ячеек и не достаточно для других.
Но процессор может влиять на напряжение питания, меняя свой потребляемый ток. Ток максимальный при максимальной тактовой частоте, при включённой внутренней периферии, для повышения тока можно даже устроить конфликт на линии ввода-вывода, настроив как выход линию порта, подключённую к выходу другой микросхемы и устаовиви протовоположный логический уровень.
Стабилизатор не сразу отрабатывает блоски тока, давая кратковременное снижение питания при резком увеличении тока и кратковременное увеличение питания при резком снижении тока.
Тогда порядок действий может быть такой:
- Увеличиваем потребление.
- Проверяем питание с помощью тестовых ячеек FRAM.
- Снижаем потребление.
- Читаеи или пишем в FRAM полезные данные.
И нужно конечно выяснить, какие ещё ячейки FRAM портятся заодно с той при обращении к которой пропало питание.

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

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

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

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

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

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

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

FM24C64

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


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

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

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

Всё проще. Полная аналогия с обычной статической RAM - при пассивном CS информация сохраняется, н-р, до 1.2 В, но стоит при таком питании просто дёрнуть CS, и про инфу можно забыть.
Чтение из FRAM внутри чипа выполняется как чтение + запись прочитанного обратно. Для упрощения логики дешифратора адреса это внутреннее чтение/запись выполняется не с одним битом или байтом, а со строкой.
Я не возьмусь предсказать, когда и до какой степени нелогичным станет поведение логики командоаппарата во FRAM при плавно падающем питании и активном CS. Затраты энергии на собственно запись в ячейку памяти у FRAM мизерные, и эта запись успешно выполнится даже когда, н-р, КМОП регистр, в который производилось чтение, уже совсем неуверено различает 0 и 1.

Нужен буфер между процом и фрам, чтобы фрам через защитные диоды на входах не запитывалась.
А так - да, R||C по питанию фрам, чтобы получить предсказуемую dU/dt, и читать до сбоя. Напряжение питания, соответствующее предшествующему сбою времени чтения, можно считать критическим.

Я сейчас небольшую крамолу скажу...

Мы уже несколько лет продаём железки (счёт - на тысячи), в которых контроллер (LPC2138, LPC2368, LPC1768) непрерывно опрашивает одну ячейку FRAM.
К стыду своему, о проблеме не задумывался. Пишем мы туда но очень-то и часто, к тому же предусмотрен механизм транзакций, который частичную запись должен откатить. О том, что может нагадить чтение, никто не подумал...
Итого, десяток обращений, связанных с бракованной FRAM (была какая-то партия, в какой-то момент там мог установиться один бит и не сбрасываться никак. При нагреве м/с феном эффект исчезал). Хоть сколько-то массовой ругани "у меня данные слетают" не было.

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

Но за тему большое спасибо. Пойду срочно внедрять кэш флагов в ОЗУ.

Может быть чем-то поможет)
В своем проекте на STM32F217 для хранения лог событий системы и настроек использовали внешнюю flash-память. По ходу возникла проблема: если при записи данных во внешнюю флеш дернуть питание, то данные все слетят. Соответственно для решения придумали такую вещь:
У данного контроллера есть энергонезависимая память Backup SRAM, в которой организовали очередь записи во внешнюю флеш. Таким образом, если нужно было что-то записать во внешнюю флеш, данные сначала записывались в Backup SRAM на контроллере. Затем если внешняя флеш была готова к записи, считывали из очереди данные и писали во внешнюю флеш. После окончания записи, считывали вновь записанные данные из внешней флеш и сравнивали с данными, которые хранятся в Backup SRAM. Если данные не совпадали, то снова пытались записать их во внешнюю флеш. Если же данные совпадали, то сдвигали очередь в Backup SRAM влево, удаляя при этом первый элемент.
Таким образом проблему решили, при сбросе питания данные во флеш не терялись, и при восстановлении нормальной работы могли быть заново записаны из Backup SRAM.

Столкнулся с похожей проблемой.

причем платы тоже напечатаны и запаяны.

есть проект на

dsPic33

в схеме также есть супервизор/вотчдог ADM706SAR

который дергает ресет DsPic33

и микросхема fram FM25V-206

подключенная по спи к микроконтроллеру. выход CS управляется с ноги контроллера, а выход HOLD микросхемы, подтянут через резистор к питанию.

память на микрухе организованна в файловую систему FAT посредством Chan овской библиотеки.

так вот имеется такая неприятная ситуация,

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

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

По ДЩ сброс супервизором МК происходит при 2.93 в
микросхема FRAM же работоспособна до 2.7

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


ДЩ на микросхему прочел, нигде никаких рекомендаций по отключению питания не обнаружил.

Почему было не подтянуть и CS к питанию?


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