Comments 26
Да все верно написали.
Я просто ошибочно написал название функции в которую у меня все немаскируемые прерывания прилетают. Исправлю.
По поводу одиночной ошибки при изменении одного бита не уверен.
Мне кажется логичным что при каждой записи записывается и ECC. И ECC пишется в ту же Flash. Т.е. искажается и бит и ECC, что в результате приведёт сразу к двойной ошибке.
Я некоторое время думал об этом и искал алгоритм ECC от ST, но не нашёл.
Опять же вычислительная сложность не ясна. Если это потребует итераций или больших таблиц, то тоже не вариант.
Проще уж рационально писать файлы. Не писать файлы из одного байта.
Алгоритм ECC нужен для того чтобы сформировать дескриптор для подходящей ECC чтобы не было ошибки или была только одна.
Потому что если будет две, то я просто не смогу прочитать ничего в дескрипторе.
Bus Fault возникает до того как выполниться команда чтения. Чтобы ни пытался читать в 32-байтном блоке будет Bus Fault и я не узнаю содержимое ни одного байта.
Кстати пустые места в дескрипторах не такая уж и проблема, а скорее фича.
Туда позже можно добавлять дату или другую метаинформацию, для шифрования например
Так адрес возврата указывается до команды чтения вызывающей ошибку. Попытка просто вернуться мгновенно вызывает новый Bus Fault.
Т.е. чтобы корректно вернуться после этой команды надо будет провести такой не слабый парсинг на предмет что там дальше за коды чтобы попасть в безопасное место после команды вызвавшей исключение.
Я пришёл к выводу что в таком случае уже нужно сгребать все логи и ресетиться.
Спасибо!
В моей файловой системе системе данные также пишутся по кругу. Посмотрите на анимацию, там это явно видно. Дескрипторы для данных по любому нужны в любой файловой системе. Называться только может по другому. Иначе нельзя будет найти где данные начинаются, а где кончаются.
Индекс в моей системе не нужен, она настолько мала, что любая операция способна прочитать всю файловую систему менее чем за 10 мс если ей требуется что-то найти. Это резко снижает потребность в RAM.
Если дескриптор не записали, то файл от этого не теряется. Теряется только последняя запись. И да моя файловая система обеспечивает такой же антисбойный механизм как и любые другие журналируемые системы. Только я его не рекламирую потому что не делал для этого тестовый проект и не делал исследования состояний не до конца стёртых секторов. Это дополнительная большая работа, поэтому у меня на этот счёт есть свои эвристики, но они не стоят того чтобы публиковать.
Нельзя забывать и о наличии механизма исправления одиночных ошибок в STM32 и предупреждения о них. Механизм работает, поскольку я сохранил в системе нативный формат записи 32-байтными словами. Такой фичи нет, скажем в SPI флэш или в JFFS для общего случая.
Поэтому я могу считать свою систему даже потенциально более надёжной чем обычные. Но требуется конечно доработки.
Примеры Embedded Flash хранилищ, которые прекрасно работают:
https://docs.zephyrproject.org/latest/reference/storage/nvs/nvs.html
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/lib_fds.html
Да, наверно я плохо объяснил преимущества именованных файлов, поиска по имени и переименований.
Надеюсь в следующем Example3 это продемонстрировать.
А эти примеры учитывают ограничение MCU на запрет до-записи flash интервалов?
FDS от Nordic плох тем, что не позволяет записывать однобайтовые payload-ы....
Минимальные данные аж 4байта! Это как понимать вообще?
Это что надо было курить, чтобы так сделать?
Обнаружил на github программный компонент fds по имени функции fds_record_write.
Попробовал собрать отдельно программный компонент fds (на LapTop PC)
клонировал репозиторий
nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac_min (master)
fds потребовал файл sdk_common.h ->sdk_config.h
при этом nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac_min sdk_config.h отсутствует. Даже если прописать пустой, то требует много зависимостей (nrf_error.h функцию __REV() и cmsis прочее). На PC fds не верифицировать.
Отсюда вывод:
fds от Nordic имеет ценность только для микроконтроллеров Nordic. Не более.
A для Artery, YunTu, FlagChip, Stm, TI, MIK32 и прочее нужен какой-то другой, более переносимый NVRAM.
Примеры Embedded Flash хранилищ, которые прекрасно работают:
Как мне сказали в Samsung-е
"Все программисты делятся на две группы: одни любят писать весь код сами, другие предпочитают только портировать чужой open‑source код. "
хороший проект, разумный и тщательный подход.
Я бы один контроллер при испытаниях "до дыр" дозаписывал, чтобы посмотреть, как оно реально себя ведет, и как обрабатываются ошибки, и примерно когда это наступает. (конечно, ресурс - это статистическая штука). И дальше бы продолжил износ, чтобы определить (разброс ресурса секторов у данного контроллера).
В тестовой программе можно сделать обязательный контроль только что записанной информации.
за время отладки, "протирал" как stm32 так и nrf52.
Поведение было одно и тоже: увеличивается время записи во Flash. после записи верификация успешная, после сброса - уже нет. содержимое памяти становится случайным на странице\секторе. Некоторые участки поддаются идентификации, но как правило это два-три слова стоящие подряд. Дальше снова хаос. и это для контроллеров, у которых заявлено наличие ECC. так что чудес я бы не ожидал
При удалении файлов ничего не стирается, но только в дескрипторы файлов записывается тэг удаленных.
А как быть с микроконтроллерами, которые не позволяют дописывать Flash память?
все что надо для встраиваемого софта малых систем все есть.
Вот у меня на столе лежит МК FC7300x, который позволяет только один раз писать страницы по 128 байт.
Попытки дописать ничего не меняют. Далее только чтение или старание сектора 8kByte.
Конкретно у STM32H753VIH цельные блоки имеют размер 32 байта, а минимальные стираемые секторы 128 Кбайт. Т.е. можно записывать за одну итерацию во Flash только блоками по 32 байта называемыми Flash word, не больше и не меньше, только один раз в одно место после последнего стирания, но стирать можно только блоками по 128 Кбайт. Если попытаться повторно записать что-то во Flash, даже если это будет один байт и он просто поменяет один бит с 1 на 0, то 32-байтный блок, на который придется такая запись, будет с высокой вероятностью обозначен системой как сбойный и последующее чтение в границах этого блока вызовет ошибку доступа к шине и вызов исключения BusFault, которое нарушит ход выполнения программы. И такое поведение никак отключить нельзя. Т.е. после некорректной записи всего в один байт в системе станет недоступным блок Flash памяти размером в 32 байта и его невозможно будет читать ни внутренней программой, ни с помощью отладочного адаптера, пока не будет стерт весь сектор128 Кбайт содержащий этот блок. Указанные ограничения препятствует использованию файловых систем типа SPIFFS или littlefs. Требуется более специфичный подход.
У меня на FC7300х всё то же самое, только параметры другие
1--запись страницами по 128 байт
2--стирание секторами по 8k Byte
И из-за этого я не могу применить Ваш STfs, так как выделять на токен стирания 128 байт - это уж как-то слишком.
Почему бы просто не взять и портировать littleFS? Он как раз делает wear leveling и не производит до запись страниц flash?
Открытый проект файловой системы для внутренней памяти STM32H