mantech, вы неправильно поняли смысл сообщения. Думаю, что под "верхним ПО" - Hold подразумевал серверную часть на компе, которая тащит данные с устройства.
А прошивку просто есть возможность загнать в устройство, ну или проверить файл на флешке на актуальность.

И часто такое бывает? По какой причине?

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

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



В случае питания и ионистора - это просчет проектирования устройства. Питания должно хватать при записи максимально возможного блока и еще +25-40% на деградирование ионистора.

Иногда есть масса-габаритные ограничения, поэтому приходится применять то, что есть и перестраховываться.

Лет надцать это наверно имело место быть, но сегодня и ионисторы и литиевые аккумы стали очень маленькие, и китайцы умудряются в спичечный коробок засунуть плату с МК и памятью, экранчик, камеру, динамик и литиевый аккум на 2 часа работы

Питания ионистора хватает на то, чтобы несколько раз перезаписать всю FRAM. У LTC3226 LDO на выходе, поэтому 3.3 держится до последнего. Точно не вспомню, но около 2-3 секунд есть. Плюс, имеет выходы, сигнализирующие о переключении на резерв, и тогда проц штатно завершает все операции и готовится отрубиться.
Верхнее ПО не хранится нигде в устройстве, это действительно бессмысленно. Возможно я несколько двусиысленно написал.
Насчет ошибок FRAM - никто не может дать гарантию, что их не может быть при штатной работе. За все время она была одна и бэкап спас. Причину её возникновения выяснить не удалось. Просто один битик записался не так и crc не сошлась.

Сообщение отредактировал Hold - Oct 18 2017, 18:33

Видимо для этого и нужно держать в кеше в ОЗУ образы AT45. Чтобы (не дай бог!) не вызвать задержку с ответом верхнему ПО в целую миллисекунду(!!!) когда оно, раз в сутки, наконец-то решит обратиться.



Столько слов о неких мифических глюках в софте и компа и SD-карты и чего там ещё.... А когда эти самые "бэкапы FRAM" Вы у себя в AT45 пишете, то что при этом делается со штатной работой ПО, которое эти данные во FRAM пишет? Атомарность этих данных у Вас конечно поддерживается? И как Вы этого добиваетесь? Приостанавливаете всю работу устройства на время бэкапа FRAM?
А если при модификации любых рабочих данных во FRAM произойдёт сбой питания к примеру? Или сбой питания при записи всех этих бекапов/логов в AT45/SD?


Наверное каждый раз при взрывах сверхновых в соседней галактике. Вы разве не защищаетесь от этого??


А причём тут заряд ионистора и "не хватит дописать страницу"? Может всё-таки руки?
А если не выключение питания, а скажем мощная помеха по цепям питания? Или ещё хуже - пачка помех (что очень часто бывает в жизни).

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


Это нужно только если все данные хранить и модифицировать в ОЗУ и скидывать их в энергонезависимую память только при аварии питания.
Если писать в энергонезависимую память при каждом изменении данных, то никаких ионисторов не нужно вообще.


А если у автора его СТО находится где-нить зимой в ХМАО к примеру? И нерадивый слесарь не закрыл ворота? Что будет если на этот "спичечный коробок" дунет ветерком этак под минус 60 по Цельсию? Вот уж точно - ошибка FRAM будет обеспечена


Причины "ошибок FRAM" как правило: либо баги ПО, управляющего этой самой FRAM; либо помехи по шине из-за плохой разводки.

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

Ну ладно. Но атомарность записи блоков данных во FRAM к примеру обеспечиваете?
Что будет если во время записи такого блока в его середине отключится питание или произойдёт перезапуск МК по помехе?

Атомарность, он же совместный доступ, обеспечивается мьютексами. Фрамка шустрая, тормоза незаметны. Питание отключиться может, для этих целей ионистор. При отключении питания все операции штатно завершаются, новые запрещаются. Перезапуск МК может быть, но пока с таким не сталкивался. В любом случае при старте память проверяется.

Атомарность != совместный доступ.
Атомарность - это непрерывность операции или неделимость данных. В данном случае я имел в виду, что любой записываемый функциональный блок данных на FRAM, должен записываться как единый неделимый объект. Т.е. - если стартовала операция записи объекта то в конце концов будет или записан новый объект или остался старый объект (до записи) и никаких промежуточных состояний (часть нового объекта успела записаться поверх старого, остальная часть - осталась от старого).


Т.е. - новые данные у Вас пишутся поверх старых и никакой защиты от внезапного прерывания записи и перезапуска устройства у вас нет?
Если перезапуск случится в момент записи некоего важного объекта данных, то и новый объект будет потерян и старый тоже.
В моих устройствах, где нужно ответственное хранение, я обеспечиваю атомарность модификации объектов (во FRAM/FLASH).
Вы пытаетесь защищаться от каких-то мифических проблем, нагромождая винегрет из разных типов памяти, при этом совершенно не решая очевидную проблему.
Если её корректно решите - больше никакие дублирования и троирования данных не нужны будут.

Да там столько дублирований, ну произойдет...Продублируется еще раз и так до победы!

На STM32F407 сделал mass storage in ram. Выделил 64 КБайта. Мне нужно с компа писать файл на этот раздел и его использовать в микроконтроллере. Для чтения файла использую fatfs.
RAM не инициализирую поэтому после каждого включения винда просит отформатировать раздел.
Под Win10 все работает как надо. Форматирую раздел, записываю файл с нужным мне именем, читаю.
Под Win8 не хочет, говорит что файла не существует.
Для отладки добавил вывод содержимого раздела как здесь http://elm-chan.org/fsw/ff/doc/readdir.html
Под win10 все отлично, показывает имена папок и файлов которые я создаю на разделе.
Под win8 не видит ни файлов ни папок созданных на разделе. Файлы туда пишутся, в дебаггере вижу что в этих 64 КБ памяти появляется и имя файла и содержимое.
Что с этим делать?

Признаться да, такой защиты у меня нет, новые данные пишутся поверх старых. Единственный способ отследить ошибку - несоответствие crc. Выделять временный буфер в той же fram, туда писать новые данные, а затем перекидывать в рабочую область? Что помешает контроллеру сброситься в момент перезаписи?
Дублирование только одно - ежедневная копия fram во flash. Никаких других нет. Буду рад конструктивным советам. От внезапного прерывания по питанию спасает ионистор.