[xemul 0]

Может быть.... однако если идет команда чтения..... ну улетел ниос.... Это как он должен улелеть? пошла команда на чтение.... ниос полетел и вместо чтения передал команду врайт-протект, потом снял cs, потом выставил cs и передал команду записи и записал кудато мусор.

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

Чтение из FRAM внутри чипа выполняется как чтение + запись прочитанного обратно. Для упрощения логики дешифратора адреса это внутреннее чтение/запись выполняется не с одним битом или байтом, а со строкой.

Я не возьмусь предсказать, когда и до какой степени нелогичным станет поведение логики командоаппарата во FRAM при плавно падающем питании и активном CS. Затраты энергии на собственно запись в ячейку памяти у FRAM мизерные, и эта запись успешно выполнится даже когда, н-р, КМОП регистр, в который производилось чтение, уже совсем неуверено различает 0 и 1.

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

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

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

[esaulenka 5]

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

 

Мы уже несколько лет продаём железки (счёт - на тысячи), в которых контроллер (LPC2138, LPC2368, LPC1768) непрерывно опрашивает одну ячейку FRAM.

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

Итого, десяток обращений, связанных с бракованной FRAM (была какая-то партия, в какой-то момент там мог установиться один бит и не сбрасываться никак. При нагреве м/с феном эффект исчезал). Хоть сколько-то массовой ругани "у меня данные слетают" не было.

 

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

 

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

[spoluer 0]

Может быть чем-то поможет)

В своем проекте на STM32F217 для хранения лог событий системы и настроек использовали внешнюю flash-память. По ходу возникла проблема: если при записи данных во внешнюю флеш дернуть питание, то данные все слетят. Соответственно для решения придумали такую вещь:

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

Таким образом проблему решили, при сбросе питания данные во флеш не терялись, и при восстановлении нормальной работы могли быть заново записаны из Backup SRAM.

[InDepth 0]

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

 

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

 

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

 

dsPic33

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

По ДЩ сброс супервизором МК происходит при 2.93 в

микросхема FRAM же работоспособна до 2.7

 

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

 

 

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

 

 

[Артём__ 0]

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

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

 

Hold: The /HOLD pin is used when the host CPU must interrupt a memory operation

for another task. When /HOLD is low, the current operation is suspended. The device

ignores any transition on SCK or /CS. All transitions on /HOLD must occur while

SCK is low

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

[InDepth 0]

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

 

 

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

 

 

из ДЩ

 

However, if it is not used,

the /HOLD pin should be tied to VDD.

 

если Холд не используется он должен быть подтянут к питанию.

[GenaSPB 11]

1) подтянуть CS к питанию

2) по рекомендации производителя пропустить CS через gate с сигналом от супервизора.

 

если Холд не используется он должен быть подтянут к питанию.

Начать использовать.

Для проверки подать на /HOLD сигнал с супервизора (сброс нулём? Тогда просто соединить) и посмотреть, изменится что-либо в поведении платы.

Изменено 26 ноября, 2012 пользователем Genadi Zawidowski

[bookd 0]

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

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

 

Память не может просто так затираться полностью. Это означает что либо в нее пишутся нули неконтролируемым образом, либо она продолжает работать при питании ниже 2V. Проц не может по SPI гнать нули достаточно долго, чтобы успеть затереть всю память. Остается ситуация, когда в FRAM идет запись при питании ниже 2V.

Это возможно если сигнал сброса достаточно "медленный", что означает схема сброса сделана неправильно. Но это предположение.

Короче, либо надо увидеть схему сброса, либо запитать FRAM через RC цепь, резистор 100ом, конденсатор 100uF, чтобы при пропадании питания даже если вся схема упала, FRAM продолжала работать на емкости конденсатора. С конденсатором 100uF в данной схеме FRAM продержится 3ms после того, как в остальной схеме полностью упало питание.

И все подтяжки на сигналы FRAM сделать непосредственно на питании от этого конденсатора.

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

Изменено 26 ноября, 2012 пользователем bookd