Jump to content

    
Sign in to follow this  
User1285

Как обеспечить целостность данных в EEPROM памяти и FLASH памяти с постраничным стиранием?

Recommended Posts

Добрый день!

Возникла проблема с обеспечением целостности данных при хранении данных в памяти с постраничным стиранием.
Память AT45DB321.

В частности есть устройство, которое имеет много сохраненных в памяти структур данных. Эти структуры никак не связаны друг с другом, они могут в произвольном порядке изменяться с сервера, добавляться новые, деактивироваться старые.
И вот тут я задумался о том как быть с потенциально возможной ситуацией:
- прилетело уведомление что нужно заменить структуру STRUCT_N, которая находиться посереди страницы памяти MEM_PAGE_X,
- я запускаю процесс перезаписи страницы (либо путем вычитки страницы в ОЗУ и заменой нужных мне данных, либо внутренними стредствами микросхемы),
- в процессе перезаписи произошел сбой питания, оно пропало (либо после стирания, либо когда данные начали грузиться в память),
- после восстановления питания у меня получается ситуация что кроме текущей редактируемой структуры у меня пострадали еще структуры, находящиеся на той же странице что и редактируемая структура. Да, я не получил от девайса ответа что редактируемая структура была изменена и я повторю данную операцию. Но как быть с остальными данными?

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

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

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

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

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

Share this post


Link to post
Share on other sites
22 minutes ago, User1285 said:

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

- По возможности не держать разные структуры в одной странице

- При операциях записи предварительно сохранять старые данные в другой странице (страницах), или вообще ввести кольцевой буфер с сохранением N старых версий, если память позволяет

Share this post


Link to post
Share on other sites
26 минут назад, User1285 сказал:

- в процессе перезаписи произошел сбой питания, оно пропало (либо после стирания, либо когда данные начали грузиться в память),
- после восстановления питания у меня получается ситуация что кроме текущей редактируемой структуры у меня пострадали еще структуры, находящиеся на той же странице что и редактируемая структура. Да, я не получил от девайса ответа что редактируемая структура была изменена и я повторю данную операцию. Но как быть с остальными данными?

100500 раз уже обсуждали подобные вопросы - воспользуйтесь поиском.

Главное правило (кратко): Никогда не писать поверх!

Т.е. - хотите что-то изменить (участок какой-то структуры во флешь)? Сперва создайте её копию (с изменённым участком) в новом месте (новой странице). И только после этого стирайте старую страницу.

Share this post


Link to post
Share on other sites
On 2/11/2021 at 2:44 PM, User1285 said:

Добрый день!

Возникла проблема с обеспечением целостности данных при хранении данных в памяти с постраничным стиранием.
Память AT45DB321.

В частности есть устройство, которое имеет много сохраненных в памяти структур данных. Эти структуры никак не связаны друг с другом, они могут в произвольном порядке изменяться с сервера, добавляться новые, деактивироваться старые.
И вот тут я задумался о том как быть с потенциально возможной ситуацией:
- прилетело уведомление что нужно заменить структуру STRUCT_N, которая находиться посереди страницы памяти MEM_PAGE_X,
- я запускаю процесс перезаписи страницы (либо путем вычитки страницы в ОЗУ и заменой нужных мне данных, либо внутренними стредствами микросхемы),
- в процессе перезаписи произошел сбой питания, оно пропало (либо после стирания, либо когда данные начали грузиться в память),
- после восстановления питания у меня получается ситуация что кроме текущей редактируемой структуры у меня пострадали еще структуры, находящиеся на той же странице что и редактируемая структура. Да, я не получил от девайса ответа что редактируемая структура была изменена и я повторю данную операцию. Но как быть с остальными данными?

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

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

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

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

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

https://www.latticesemi.com/view_document?document_id=46423

https://ru.wikipedia.org/wiki/%D0%96%D1%83%D1%80%D0%BD%D0%B0%D0%BB%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D0%B0%D1%8F_%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0

или полное дублирование флэш во второй флэш "Two BIOS Chips, Dual Protection!" https://www.biostar.com.tw/app/en/event/dualbios/index.htm

 

 

Share this post


Link to post
Share on other sites

Всем спасибо за помощь!

Буду пробовать реализовать дублирование памяти. Кольцевой буфер с N старых версий проблематичен, потому как это, как мне кажеться) усложнит сильно алгоритм. Я добавлю к каждой записи контрольную сумму и в случае если контрольная сумма некорректная, то пытаюсь прочитать те же данные из второй копии памяти. А если и там проблемы с контрольной суммой, тогда буду считать данные не валидными и уведомлять сервер о проблеме.

Интересно нужно ли в случае применения flash памяти типа AT45DF добавлять алгоритм разметки bad ячеек, чтобы если данные побились в ячейке, то исключать ее из дальнейшего использования...

Share this post


Link to post
Share on other sites
2 часа назад, User1285 сказал:

Буду пробовать реализовать дублирование памяти. Кольцевой буфер с N старых версий проблематичен, потому как это, как мне кажеться) усложнит сильно алгоритм. Я добавлю к каждой записи контрольную сумму и в случае если контрольная сумма некорректная, то пытаюсь прочитать те же данные из второй копии памяти. А если и там проблемы с контрольной суммой, тогда буду считать данные не валидными и уведомлять сервер о проблеме.

Непонятно - зачем вообще задавали вопрос, если в результате решили не обеспечивать устойчивость к сбоям питания/перезагрузкам никак?  :wacko2:

Share this post


Link to post
Share on other sites
3 hours ago, jcxz said:

Непонятно - зачем вообще задавали вопрос, если в результате решили не обеспечивать устойчивость к сбоям питания/перезагрузкам никак?  :wacko2:

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

Share this post


Link to post
Share on other sites
1 час назад, User1285 сказал:

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

А причём тут...? Думаете это резервное питание предохранит от внезапных перезагрузок устройства?

Share this post


Link to post
Share on other sites

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

Буду очень благодарен если подскажете на какие еще возможные ситуации мне стоит обратить внимание и что еще может привести к перегрузке (будем считать что алгоритм будет работать так что не вызовет сброс по watchdog-у).

Share this post


Link to post
Share on other sites
5 часов назад, User1285 сказал:

перегрузке

Ну, падение устройства со стола может привести к перегрузке. Но если вы имеете в виду перезагрузку, то не вижу название микроконтроллера/процессора/ПЛИС, с которым вы работаете? Думаю, что по статистике большинства, у вас что-нибудь на основе Cortex-Mx. В этом случае к перезагрузке может привести ошибка программы, приводящая к вызову прерывания HardFault. Нередко там вместо адекватного обработчика встречается бесконечный цикл по-умолчанию. Вот это, если у вас включена сторожевая собака, приведёт к перезагрузке. Если не включена, то это будет "зависанием" прибора. К HardFault приводят самые разнообразные ошибки, например:

1. Попытка выполнить код из области памяти ввода-вывода.

2. Невыровненный доступ всегда на Cortex-M0 и при условии, что опция включена на Cortex-M3/M4 (про M7 не в курсе).

3. Попытка выполнить неизвестную процессору инструкцию.

4. Попытка обратиться к математическому сопроцессору на Cortex-M4F если тот не включен.

5. И другие, см. документацию.

Возможно, что на уровне "кэпа", но аппаратные ошибки тоже могут привести к перезагрузке.

Share this post


Link to post
Share on other sites
13 часов назад, User1285 сказал:

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

Кроме "статики" бывают и другие виды помех. И гарантия устойчивости к их влиянию это - проведение полных испытаний на ЭМС, а не надежды на какие-то "развязки". Гальваническая развязка никак не гарантирует устойчивости изделия к разным видам ЭМ-помех.

А то, на что Вы надеетесь - это класс функционирования A (по ГОСТ Р 51317.4.2). И его не так-то просто достичь. Особенно без опыта. А может вообще невозможно для каких-то типов оборудования.

 

Прошли испытания по ГОСТ Р 51317.4.2 (или какой на Украине его аналог) ?

Подтвердили класс A?

Если нет - значит изделие будет перезапускаться от помех (это в лучшем случае). :unknw:

 

PS: По моему опыту: Проще обеспечить устойчивость системы хранения данных к внезапным перезагрузкам ПО (программно-аппаратными средствами), чем обеспечить класс функционирования A. Для 2-го может потребоваться не одна переразводка платы. С кучей испытаний.

Share this post


Link to post
Share on other sites
13 часов назад, User1285 сказал:

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

Не нужна для этого развяка. Угробите развязку статикой. Возьмите TVS и не мучайтесь) Мы используем 1.5SMCxxCA. Проверяем пистолетом 8 кВ. Никакого выхода из строя компонентов схемы.

21 минуту назад, jcxz сказал:

А то, на что Вы надеетесь - это класс функционирования A (по ГОСТ Р 51317.4.2). И его не так-то просто достичь.

Дико плюсую. По собственному опыту. Был случай, когда "стреляли" пистолетом в пластиковую панель устроства, на которую выходили светодиоды, но не доходили до панели 5 мм. И плата была расположена на глубине 30 мм от этой же панели. Примерно каждый 20 "чих" пистолетом приводил к перезагрузке устройства. Решили проблему коллективно, переразведя плату.

Share this post


Link to post
Share on other sites
7 минут назад, MrBearManul сказал:

Был случай, когда "стреляли" пистолетом в пластиковую панель устроства, на которую выходили светодиоды, но не доходили до панели 5 мм. И плата была расположена на глубине 30 мм от этой же панели. Примерно каждый 20 "чих" пистолетом приводил к перезагрузке устройства. Решили проблему коллективно, переразведя плату.

Вот именно. А стрелять, кста, надо было прямо в светодиоды (насколько помню свои испытания).  :wink:

Share this post


Link to post
Share on other sites
3 минуты назад, jcxz сказал:

А стрелять, кста, надо было прямо в светодиоды (насколько помню свои испытания).  :wink:

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

Share this post


Link to post
Share on other sites
16 минут назад, MrBearManul сказал:

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

У нас тоже подобное было. Когда стреляли в пластиковый корпус. На нём с внутренней стороны была напылена металлизация и видимо ток от разряда, растекаясь по этой металлизации, как-то воздействовал на цепи внутри.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this