[User1285 0]

Добрый день!

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

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

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

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

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

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

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

[aaarrr 63]

22 minutes ago, User1285 said:

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

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

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

[jcxz 184]

26 минут назад, User1285 сказал:

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

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

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

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

[gosha 0]

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

 

 

[User1285 0]

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

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

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

[jcxz 184]

2 часа назад, User1285 сказал:

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

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

[User1285 0]

3 hours ago, jcxz said:

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

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

[jcxz 184]

1 час назад, User1285 сказал:

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

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

[User1285 0]

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

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

[MrBearManul 0]

5 часов назад, User1285 сказал:

перегрузке

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

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

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

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

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

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

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

[jcxz 184]

13 часов назад, User1285 сказал:

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

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

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

 

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

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

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

 

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

[MrBearManul 0]

13 часов назад, User1285 сказал:

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

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

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

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

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

[jcxz 184]

7 минут назад, MrBearManul сказал:

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

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

[MrBearManul 0]

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

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

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

[jcxz 184]

16 минут назад, MrBearManul сказал:

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

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