Алгоритм стирания Флеш. Алгоритм выравнивания износа при записи данных

[mantech 1]

4 часа назад, TViT сказал:

Что будет физически во флеш FF везде? Ну кроме например сбойного бита или байта не важно.

Ну так и будет, вот представьте себе, флеш организован в виде матрицы, на строку подают напряжение стирания, весь заряд сбрасывается на всей строке, не важно, были там сбойные ячейки или нет. Сбой - это просто заряд, 1, но по уровню, почти или чуть ниже значения 0, это если SLC ячейка. Поэтому все и сотрется одновременно.

[Eddy_Em 0]

36 minutes ago, jcxz said:

В современных МК объём флеша таков, что хватит нескольких миллисекунд чтобы весь его прочитать

Ложь. Даже через st-link прошивка каждых 10кБ длится достаточно долго.

[makc 7]

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

Ложь. Даже через st-link прошивка каждых 10кБ длится достаточно долго.

Вы путаете запись, требующую стирания, и чтение. @jcxz написал именно о чтении и если считать рабочей частоту флеша 25 МГц, а ширину его шины не менее 4 байт, то время чтения посчитать совсем несложно. Сколько получается требуется на чтение 256 кБайт? ;-)

[TViT 0]

22 минуты назад, mantech сказал:

Поэтому все и сотрется одновременно.

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

[mantech 1]

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

Как же одновременно если построчно стирается?

Это я привел для аналогии. Строка бывает по неск. килобайт. И еще их объединяют в блок.

Edited May 4 by mantech

[jcxz 4]

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

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

Судя по даташиту, на линейное чтение всей флешь этого МК единой транзакцией нужно: 128*1024/(24e6*8) = ~683мкс. Если я правильно понял написанное в даташите. Конечно - в реале будет немного больше из-за накладных расходов на организацию цикла и на операции сравнения и на неоптимальность частоты тактирования и т.п.. Но всё равно - я даже примерно не могу представить как можно умудриться затормозить эту процедуру в 7324 раза!!!

Ну в 2, 3, ну в 10 раз - ещё куда ни шло. Но не в 7324 раза, Карл!!! Вы видимо очень старались.  

4 часа назад, jcxz сказал:

В современных МК объём флеша таков, что хватит нескольких миллисекунд чтобы весь его прочитать.

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

Ложь. Даже через st-link прошивка каждых 10кБ длится достаточно долго.

Включите голову хоть на несколько секунд! Причём тут прошивка, когда речь о чтении???

Вы понимаете разницу между чтением и стиранием/записью? Нет?  

3 часа назад, TViT сказал:

А если построчно, то что сделает контроллер когда определенная строка не стерлась? Идет дальше стирает остальные строки и уже потом на верхнем уровне функция стирания проверяет регистр состояния и выкидывает ошибку?

Не знаю как в STM32, но в XMC4xxx процесс стирания 256K-сектора занимает до <=5.5сек. Но этот МК умеет формировать биты статуса результата стирания. Может именно поэтому там такой длительный процесс стирания. И проверка качества стирания там похоже состоит не в простом обратном чтении, а что-то более сложное делается.

[Eddy_Em 0]

4 hours ago, makc said:

Сколько получается требуется на чтение 256 кБайт? ;-)

1) Считали 32 байта. 2) Проверили magick. 3) Не годится? Перешли к п. 1).

А если блоки еще более мелкие, то это затянется еще сильней!

И да, может, я запускаю процедуру чтения до инициализации тактирования? =D

Edited May 4 by Eddy_Em

[makc 7]

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

1) Считали 32 байта. 2) Проверили magick. 3) Не годится? Перешли к п. 1).

А если блоки еще более мелкие, то это затянется еще сильней!

И да, может, я запускаю процедуру чтения до инициализации тактирования? =D

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

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

Включите голову хоть на несколько секунд! Причём тут прошивка, когда речь о чтении???

И причем здесь st-link тоже непонятно.

[amaora 0]

Не очень понимаю как использовать эти неизвестные аппаратные особенности стирания. Если возвращается статус cтирания, то могут быть какие-то стратегии его использования. Но для чего знать как именно контроллер "недотрет" битый сектор? В любом случае будет программный контроль целостности данных.

Edited May 4 by amaora

[Eddy_Em 0]

18 minutes ago, makc said:

И при чем здесь st-link тоже непонятно.

При том, что он дает наибольшую скорость записи. Бутлоадер через USART1 немного помедленней. А уж ждать, пока прошьется по DFU — вообще ужас!

[makc 7]

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

При том, что он дает наибольшую скорость записи. Бутлоадер через USART1 немного помедленней. А уж ждать, пока прошьется по DFU — вообще ужас!

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

[mantech 1]

04.05.2022 в 21:19, makc сказал:

По-моему вы не видите разницы

Там просто не вопрос о командных строках, вот и поплыл наш гуру)))))))

04.05.2022 в 19:50, amaora сказал:

Если возвращается статус cтирания, то могут быть какие-то стратегии его использования.

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

[Arlleex 1]

35 минут назад, mantech сказал:

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

А когда все такие флаги умеют формировать прерывания - вообще сказка для программиста.

[mantech 1]

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

А когда все такие флаги умеют формировать прерывания

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

[Arlleex 1]

5 минут назад, mantech сказал:

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

Может и так В своих крайних проектах (не сложных) у меня нет RTOS вытесняющей; там вместо нее самописный переключатель задач (считай суперцикл), и вот там нельзя тупить на время стирания/записи. Вот и очень удобно по прерываниям работать.