Комментарии 19
Да все верно написали.
Я просто ошибочно написал название функции в которую у меня все немаскируемые прерывания прилетают. Исправлю.
По поводу одиночной ошибки при изменении одного бита не уверен.
Мне кажется логичным что при каждой записи записывается и 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
хороший проект, разумный и тщательный подход.
Я бы один контроллер при испытаниях "до дыр" дозаписывал, чтобы посмотреть, как оно реально себя ведет, и как обрабатываются ошибки, и примерно когда это наступает. (конечно, ресурс - это статистическая штука). И дальше бы продолжил износ, чтобы определить (разброс ресурса секторов у данного контроллера).
В тестовой программе можно сделать обязательный контроль только что записанной информации.
за время отладки, "протирал" как stm32 так и nrf52.
Поведение было одно и тоже: увеличивается время записи во Flash. после записи верификация успешная, после сброса - уже нет. содержимое памяти становится случайным на странице\секторе. Некоторые участки поддаются идентификации, но как правило это два-три слова стоящие подряд. Дальше снова хаос. и это для контроллеров, у которых заявлено наличие ECC. так что чудес я бы не ожидал
Открытый проект файловой системы для внутренней памяти STM32H