[TViT 0]

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

Кто знает что будет в STM32 при стирании страницы если например 1 бит на странице битый, поврежденный. Функция до этого бита сотрет память и выкинет ошибку и какие-то области будут не стертыми? Или вся страница стирается и проверяется на FF после чего выдается ошибка? Можно ли потом работать и записывать в другие области этой недотертой страницы, обходя сбойные биты. Например после собственной проверки на FF, до этого сбойного бита и после где по идее должны быть единицы? Или страница помечается как битая при первом сбойном бите и дальше не стирается?

Как можно промоделировать отказ Флеш памяти. Что происходит при стирании, какой алгоритм самого контроллера флеш-памяти.

[mantech 35]

7 часов назад, TViT сказал:

Функция до этого бита сотрет память и выкинет ошибку и какие-то области будут не стертыми?

Как напишите эту функцию - так и будет. А вообще стирание страницы флеш - процесс аппаратный и ему по барабану, есть там ошибки или нет, уж потом сами проверять будете, заполнилось все пространство FF-ками или где-то "дырки"...

7 часов назад, TViT сказал:

Как можно промоделировать отказ Флеш памяти.

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

7 часов назад, TViT сказал:

какой алгоритм самого контроллера флеш-памяти.

Очень простой, отслеживать что-то и помечать должны ваши функции.

[Obam 30]

оперировать

миллионами циклов записи и стирания

Фантазёр, однако...

[TViT 0]

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

Фантазёр, однако...

Да каюсь спешил... Миллионы циклов записи данных. Стирание страницы то скорее всего будет заявленные 10000циклов * на количество страниц.

16 часов назад, mantech сказал:

Как напишите эту функцию - так и будет. А вообще стирание страницы флеш - процесс аппаратный и ему по барабану, есть там ошибки или нет, уж потом сами проверять будете, заполнилось все пространство FF-ками или где-то "дырки"...

Так не я управляю стиранием, это делает контроллер памяти. Вот в этом и вопрос как он стирает? Что будет если бит не сотрется мне функция выдаст ошибку, что процесс стирания прошел неудачно. А вот что будет во флеш памяти при этом? Контроллер сотрет до сбойного бита, и выйдет с ошибкой. Или вся страница будет стерта, а потом контроллер сам делает проверку и если там не FF уже мне на верхний уровень выдаст ошибку. При этом не стертым будет один сбойный бит? И я уже своим алгоритмов этот бит буду обходить и читать и писать дальше в другие области страницы.

16 часов назад, mantech сказал:

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

И так пока Флеш не сдохнет и не начнет сбоить?

Изменено 1 мая, 2022 пользователем TViT

[mantech 35]

15 минут назад, TViT сказал:

А вот что будет во флеш памяти при этом?

Ошибка, разумеется))

15 минут назад, TViT сказал:

Или вся страница будет стерта, а потом контроллер сам делает проверку и если там не FF уже мне на верхний уровень выдаст ошибку

Не встречал таких умных контроллеров...

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

И так пока Флеш не сдохнет и не начнет сбоить?

Ну да в общем случае, пока не пойдут ошибки стирания\записи нужных данных.

17 минут назад, TViT сказал:

Миллионы циклов записи данных.

Этого кол-ва не даст даже SLC NAND.

[jcxz 184]

30.04.2022 в 12:24, TViT сказал:

   Народ при создании файловой системы и алгоритма размазывания и надежного сохранения и восстановления данных

Размазывают кашу по тарелке. А то, о чём вы пытаетесь говорить, называется: "выравнивание износа".

Цитата

Можно ли потом работать и записывать в другие области этой недотертой страницы, обходя сбойные биты.

Флешь программ МК не работает с отдельными битами. И даже с байтами (как правило). Минимальный размер элемента записи в разных МК - разный. Может быть 32 бита, а может быть и 16 байт.

Даже в разных STM32 этот размер - разный. Определяется он размером ECC-контроля.

Например STM32WB55:

* 72-bit wide data read (64 bits plus 8 ECC bits)
* 72-bit wide data write (64 bits plus 8 ECC bits)

О размере элемента ECC-контроля в своём МК можете прочитать в его мануале.

Цитата

Как можно промоделировать отказ Флеш памяти. Что происходит при стирании, какой алгоритм самого контроллера флеш-памяти.

Вангую что в разных МК - алгоритмы отличаются. И нет универсальных.

И в некоторых МК есть даже не отказ, а прогнозирование оного. Когда стирание/запись прошли нормально, но в регистрах статуса выставляется предупреждение.

[viakon 0]

в стм нет проверки качества стирания страницы. Но есть проверка перед записью в ячейку. Если в ячейке не 0xffff, то запись не происходит и устанавливается бит ошибки. Исключение - запись 0. можно записать даже если ячейка не стерта.

[TViT 0]

01.05.2022 в 12:25, mantech сказал:

Этого кол-ва не даст даже SLC NAND.

Это почему, объясните? Страница 2048 байт, кол-во стираний 10000. Если нужно сохранять в этой странице одну переменную максимального размера 4 байта то при одном стирании ее можно записать 512раз. Умножаем на 10000 циклов получаем больше 5 млн записей.

01.05.2022 в 12:25, mantech сказал:

01.05.2022 в 12:10, TViT сказал:

А вот что будет во флеш памяти при этом?

Ошибка, разумеется))

Да причем тут ошибка? Это на верхнем уровне я ее получу от ф-ции стирания. Что будет физически во флеш FF везде? Ну кроме например сбойного бита или байта не важно. Алгоритм обхода просматривает память перед записью и пишет туда где FF.

Изменено 4 мая, 2022 пользователем TViT

[jcxz 184]

11 минут назад, TViT сказал:

Это почему, объясните? Страница 2048 байт, кол-во стираний 10000. Если нужно сохранять в этой странице одну переменную максимального размера 4 байта то при одном стирании ее можно записать 512раз.

Ещё раз:

01.05.2022 в 12:36, jcxz сказал:

Флешь программ МК не работает с отдельными битами. И даже с байтами (как правило). Минимальный размер элемента записи в разных МК - разный. Может быть 32 бита, а может быть и 16 байт.

Даже в разных STM32 этот размер - разный. Определяется он размером ECC-контроля.

Например STM32WB55:

* 72-bit wide data read (64 bits plus 8 ECC bits)
* 72-bit wide data write (64 bits plus 8 ECC bits)

О размере элемента ECC-контроля в своём МК можете прочитать в его мануале.

читайте мануал на ваш МК, а не фантазируйте. Сколько раз сможете записать в одну страницу - зависит от этого параметра.

[Eddy_Em 1]

Можно после записи проверять, совпадает ли записанное с записываемым. И если не совпадает - писать еще раз в следующую область памяти. Если у вас там реально всего лишь 4 байта надо писать, то бинарный поиск достаточно простой: сразу uint32_t и считываем, проверяем на 0xffffffff и далее... А вот если данных побольше, лучше какой-нибудь uint16_t magick в начале структуры положить, чтобы по нему проверять (заодно это позволит сохранять в т.ч. и 0xffffffff - в вашем случае же это число будет считаться пустой ячейкой).

[TViT 0]

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

читайте мануал на ваш МК, а не фантазируйте.

В STM32F103RET6 - 16, 32, 64 бита

 

#define FLASH_TYPEPROGRAM_HALFWORD             0x01U  /*!<Program a half-word (16-bit) at a specified address.*/
#define FLASH_TYPEPROGRAM_WORD                 0x02U  /*!<Program a word (32-bit) at a specified address.*/
#define FLASH_TYPEPROGRAM_DOUBLEWORD           0x03U  /*!<Program a double word (64-bit) at a specified address*/

 

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

Можно после записи проверять, совпадает ли записанное с записываемым.

Там все это в алгоритме надежного сохранения делается и не только это, кучу всего дополнительного еще. Просто заинтересовал вопрос именно в железе. Что будет если флеш начинает сыпаться и ф-я стирания выдает ошибку. Что будет физически во флеш памяти. Можно ли надеятся что там везде будет FF, кроме сбойного бита или байта или слова.

[Eddy_Em 1]

Честно говоря, сколько ни экспериментировал с STM32, ни разу мне не удалось достичь такого количества циклов перезаписи, чтобы убить флеш... Вот с STM8S003 такое было - но там флеш совсем дохленькая.

Да, учтите, что N гарантированных циклов - это N/2 гарантированных записей со стиранием (т.к. стереть + записать = 2 цикла). Но если хранить нужно небольшую толику данных, ресурсов флеша хватит очень надолго. Я вот сам настройки в структуре сохраняю (например). Когда структура не больше 64 байт, а в распоряжении 32 и больше килобайта флеш-памяти, настройки можно хоть каждый час менять без риска убить этим устройство… Я использую бинарный поиск последней записи (что сильно ускоряет время инициализации: многие пользуются линейным поиском, это может аж секунд на пять затянуться!), а начало секции "хранения" помечаю в ld-скрипте — это первый же сектор флеша после прошивки. В качестве magick использую просто размер структуры. Поначалу я делал ее упакованной, но когда нарвался на хардфолт при попытке доступа к невыровненному uint32_t (кажись, на "нулевке"), решил, что пусть лучше в случае чего будут "дыры" и указываю атрибут aligned(4).

Изменено 4 мая, 2022 пользователем Eddy_Em

[jcxz 184]

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

многие пользуются линейным поиском, это может аж секунд на пять затянуться!

Небылицы рассказываете. Такое может быть только если руки совсем кривые.

Или назовите конкретную модель МК, где для чтения флеша нужно "5 секунд"? С включённым кешем.

 

В современных МК объём флеша таков, что хватит нескольких миллисекунд чтобы весь его прочитать. Даже если флеша == пара МБ и поиск идёт по всему его объёму. Если конечно голова на плечах есть. А всякие бинарные поиски - наоборот только затормозят работу, так как кеш флеша в МК рассчитан на линейное чтение.

А если "5 секунд" - это с учётом того, что в данный момент может выполняться операция записи/стирания, так ваш "бинарный поиск" будет также 5 секунд ждать её завершения.

[mantech 35]

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

Или назовите конкретную модель МК, где для чтения флеша нужно "5 секунд"?

Ну может он очень вдумчиво читает))))))

[Eddy_Em 1]

33 minutes ago, jcxz said:

Или назовите конкретную модель МК, где для чтения флеша нужно "5 секунд"?

STM32F103CBT6. Прошивка на 10кБ, остальное - под эмуляцию EEPROM. Длина блока была то ли 16, то ли 20 байт. Если забить "до упора", то линейный поиск проходил почти 5 секунд: считали блок, проверили, потом считали следующий... В случае бинарного поиска хватало меньше 15 проверок!