Pull to refresh

Comments 19

Если верить Reference manual на STM32H753, при ошибке контроля ECC Programm Flash генегируется не Hard Fault, а Bus Fault, и только в случае, если была обнаружена двойная ошибка, если была обнаружена одинарная — она исправляется, и может произойти маскируемое прерывание, если оно включено. А Hard Fault возникает, если обнаружена двойная ошибка, и Bus Fault маскировано. При этом, Bus Fault можно обработать, ориентируясь на адрес и флаги от блока контроля ECC. Это, конечно, слабо поможет повторной записи, ведь блок ECC может исказить данные при чтении, пытаясь исправить одиночную ошибку — писать повторно имеет смысл разве что несколько значений из фиксированной последовательности, каждое из которых имеет корректный ECC. Или практика расходится с Reference manual?

Да все верно написали.
Я просто ошибочно написал название функции в которую у меня все немаскируемые прерывания прилетают. Исправлю.

По поводу одиночной ошибки при изменении одного бита не уверен.
Мне кажется логичным что при каждой записи записывается и ECC. И ECC пишется в ту же Flash. Т.е. искажается и бит и ECC, что в результате приведёт сразу к двойной ошибке.

Думаю, да, записывается и ECC. Но думаю, существует несколько последовательностей из 256-битных данных с кодом ЕСС, в которых следующий элемент отличается набором дополнительных нулей в данных и ECC. А если не смотря на Bus Fault всё-таки можно прочитать дескриптор — наверное можно писать маркер стирания прямо в 32-байтный дескриптор, в виде поля из нескольких нулей. Это позволит уменьшить расход памяти на запись одного байта в файл в полтора раза.

Я некоторое время думал об этом и искал алгоритм ECC от ST, но не нашёл.

Опять же вычислительная сложность не ясна. Если это потребует итераций или больших таблиц, то тоже не вариант.

Проще уж рационально писать файлы. Не писать файлы из одного байта.

Не совсем понимаю, как Вы хотели применить алгоритм ECC. Если он нужен — возможно, стоит попробовать предположение, что он принципиально такой же, какой применялся в IBM-370 ещё в 70-х, и отличается только разрядностью. Но для записи маркера стирания в 32-байтный дескриптор он не нужен — достаточно в обработчике Bus Fault игнорировать это исключение, если установлен флаг двойной ошибки ECC, а в дескрипторе первым делом проверять маркер стирания. Это может быть байт, который для нестёртого дескриптора равен FF. Для стёртого — писать туда 0, и проверять на равенство FF. Это добавит время на обработку Bus Fault по каждому удалённому дескриптору — но это немного времени.

Алгоритм ECC нужен для того чтобы сформировать дескриптор для подходящей ECC чтобы не было ошибки или была только одна.
Потому что если будет две, то я просто не смогу прочитать ничего в дескрипторе.
Bus Fault возникает до того как выполниться команда чтения. Чтобы ни пытался читать в 32-байтном блоке будет Bus Fault и я не узнаю содержимое ни одного байта.

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

Так из обработчика Bus Fault можно вернуться как из обычного прерывания, и данные скорее всего будут прочитаны

Так адрес возврата указывается до команды чтения вызывающей ошибку. Попытка просто вернуться мгновенно вызывает новый Bus Fault.

Т.е. чтобы корректно вернуться после этой команды надо будет провести такой не слабый парсинг на предмет что там дальше за коды чтобы попасть в безопасное место после команды вызвавшей исключение.

Я пришёл к выводу что в таком случае уже нужно сгребать все логи и ресетиться.

Но из Bus Fault нужно возвращаться не в общем случае, а в конкретном. Поэтому чтобы узнать на сколько прирастить адрес возврата достаточно глянуть в дизассемблер в этом месте. Правда, шансов получить значение в этом случае остаётся немного.

Хорошая идея для новой статьи.

UFO just landed and posted this here

В моей файловой системе системе данные также пишутся по кругу. Посмотрите на анимацию, там это явно видно. Дескрипторы для данных по любому нужны в любой файловой системе. Называться только может по другому. Иначе нельзя будет найти где данные начинаются, а где кончаются.
Индекс в моей системе не нужен, она настолько мала, что любая операция способна прочитать всю файловую систему менее чем за 10 мс если ей требуется что-то найти. Это резко снижает потребность в RAM.

Если дескриптор не записали, то файл от этого не теряется. Теряется только последняя запись. И да моя файловая система обеспечивает такой же антисбойный механизм как и любые другие журналируемые системы. Только я его не рекламирую потому что не делал для этого тестовый проект и не делал исследования состояний не до конца стёртых секторов. Это дополнительная большая работа, поэтому у меня на этот счёт есть свои эвристики, но они не стоят того чтобы публиковать.

Нельзя забывать и о наличии механизма исправления одиночных ошибок в STM32 и предупреждения о них. Механизм работает, поскольку я сохранил в системе нативный формат записи 32-байтными словами. Такой фичи нет, скажем в SPI флэш или в JFFS для общего случая.
Поэтому я могу считать свою систему даже потенциально более надёжной чем обычные. Но требуется конечно доработки.

Да, наверно я плохо объяснил преимущества именованных файлов, поиска по имени и переименований.
Надеюсь в следующем Example3 это продемонстрировать.

хороший проект, разумный и тщательный подход.

Я бы один контроллер при испытаниях "до дыр" дозаписывал, чтобы посмотреть, как оно реально себя ведет, и как обрабатываются ошибки, и примерно когда это наступает. (конечно, ресурс - это статистическая штука). И дальше бы продолжил износ, чтобы определить (разброс ресурса секторов у данного контроллера).

В тестовой программе можно сделать обязательный контроль только что записанной информации.

за время отладки, "протирал" как stm32 так и nrf52.

Поведение было одно и тоже: увеличивается время записи во Flash. после записи верификация успешная, после сброса - уже нет. содержимое памяти становится случайным на странице\секторе. Некоторые участки поддаются идентификации, но как правило это два-три слова стоящие подряд. Дальше снова хаос. и это для контроллеров, у которых заявлено наличие ECC. так что чудес я бы не ожидал

Sign up to leave a comment.

Articles