[jcxz 184]

Не видел нигде в документациях на МК никаких упоминаний о сабже. Интересно - выполняется ли выравнивание износа программной flash в каких-то МК? Или такого нигде нет?

Если у кого есть информация - киньте ссылки где почитать.

 

PS: Речь именно о встроенном механизме, а не о внешнем, в программе пользователя. Например: имеется отлаживаемая прошивка, часто перешиваемая, небольшого размера (а в МК много флеша). Имеет ли смысл иногда перемещать её вручную по флеши МК? Или есть встроенный механизм, который это уже делает?

[Forger 17]

А смысл? 

Насколько мне известно, ресурс флэши в МК как минимум на порядок выше, чем в тех же SSD.

Ведь в МК пока еще не используют флэш с многоуровневой записью (когда в одну ячейку пишут по 3..4 бита).

10 К циклов они точно держат и то на максимальной температуре, в реальности число циклов там гораздо больше.

 

[jcxz 184]

В 25.06.2022 в 10:35, Forger сказал:

10 К циклов они точно держат и то на максимальной температуре, в реальности число циклов там гораздо больше.

И сколько держат? По времени. Задумывались?

С увеличением количества циклов стирания/записи уменьшается максимальное время хранения этой флеши. Например для XMC4xxx мануал говорит, что максимальный retention time = 20 лет гарантируется только при количестве erase/program циклов для логического сектора <=100. Всего 100 циклов! А каков он будет при 200 циклах например? неизвестно...

 

PS: И вообще - вопрос был не "зачем?", а "имеется ли механизм?"

[Forger 17]

On 6/25/2022 at 10:49 AM, jcxz said:

а "имеется ли механизм?"

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

On 6/25/2022 at 10:49 AM, jcxz said:

И сколько держат? По времени. Задумывались?

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

Если же речь идет о каком-то уникальном изделии, где предполагается менять прошивку раз в сутки удаленно, то тут уже нужно разработчику заботиться об этом.

Включать этот механизм во ВСЕ мк ради одного уникального случая никто не будет - это никому не выгодно.

Будет спрос на такие МК, то производители сразу такое сделают. Реальный спрос, не штучный от энтузиастов.

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

 

[Segment 3]

В 25.06.2022 в 10:25, jcxz сказал:

Не видел нигде в документациях на МК никаких упоминаний о сабже. Интересно - выполняется ли выравнивание износа программной flash в каких-то МК? Или такого нигде нет?

Если у кого есть информация - киньте ссылки где почитать.

 

PS: Речь именно о встроенном механизме, а не о внешнем, в программе пользователя. Например: имеется отлаживаемая прошивка, часто перешиваемая, небольшого размера (а в МК много флеша). Имеет ли смысл иногда перемещать её вручную по флеши МК? Или есть встроенный механизм, который это уже делает?

Если речь идет о прошивке, то предполагается, что она ставится один раз и далее работает без стираний. Плюс можно добавить пару десятков обновлений прошивок, и все-равно это будет довольно мало, чтобы сильно занизить data retention. Но если у Вас блоки стирались уже 1000 раз, в среднем data retention гарантируется уже только около 10 лет (а не 20). Но опять таки, все эти 20 и 10 лет очень условны, т.к. все зависит от условий, а также от производственного брака. А если говорить о внутреннем хранилище, как это например используют в nRF SDK, то там нужно выравнивание, и еще желательно периодически данные переносить, хотябы раз в год.

Изменено 25 июня, 2022 пользователем Segment

[jcxz 184]

В 25.06.2022 в 12:09, Segment сказал:

Если речь идет о прошивке, то предполагается, что она ставится один раз и далее работает без стираний.

Для танкистов повторю ещё раз:

Вопрос был не "зачем?". Вопрос был - "имеется ли механизм?"

В 25.06.2022 в 12:09, Segment сказал:

Плюс можно добавить пару десятков обновлений прошивок, и все-равно это будет довольно мало, чтобы сильно занизить data retention. Но если у Вас блоки стирались уже 1000 раз, в среднем data retention гарантируется уже только около 10 лет (а не 20).

Я конечно понимаю, что "чукча не читатель", но может всё-таки прочитаете моё предыдущее сообщение:

В 25.06.2022 в 10:49, jcxz сказал:

Например для XMC4xxx мануал говорит, что максимальный retention time = 20 лет гарантируется только при количестве erase/program циклов для логического сектора <=100. Всего 100 циклов!

Вы считаете, что владеете более достоверными данными о характеристиках МК, чем его производитель???  

В 25.06.2022 в 10:56, Forger сказал:

Если же речь идет о каком-то уникальном изделии, где предполагается менять прошивку раз в сутки удаленно, то тут уже нужно разработчику заботиться об этом.

Удивительно - почему никто из отвечающих не удосуживается прочитать вопроса???  

В исходном вопросе было:

В 25.06.2022 в 10:25, jcxz сказал:

Например: имеется отлаживаемая прошивка, часто перешиваемая, небольшого размера (а в МК много флеша).

В реальной работе разработчика это обычная ситуация: Работает, работает программист с устройством. Много дней подряд. Перешивает его много раз за день (для несведущих - этот процесс называется "отладка ПО"). За это время могут набежать сотни и тысячи циклов перезаписи. Потом вдруг, по какой-то причине, не зависящей от программиста, срочно требуется это отлаживаемое устройство отправить как готовый продукт заказчику (такое и ранее могло случаться, а в нынешних условиях дефицита и задержек поставок комплектации это ещё более вероятно). А в гарантийных обязательствах изготовителя устройства гарантируется например срок службы изделия например >=16 лет.

 

И это только один из вариантов событий. Могут быть и другие.

 

PS: Не надо со своей колокольни судить об условиях работы и требованиях к изделиям, которые могут быть о других. Вы этих условий не знаете. И как видно - даже спрогнозировать не можете.  

PPS: И прошу не отклоняться от изначальной сути вопроса. Вопрос "зачем" - не обсуждается.

[Segment 3]

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

Изменено 25 июня, 2022 пользователем Segment

[jcxz 184]

В 25.06.2022 в 13:18, Segment сказал:

Потому что вопрос поставлен некорректно, отвечаем просто по сути проблемы. Что за механизм? Как Вы себе это представляете?

Точно так же как это сделано например в SD-картах. Ничего сложного не вижу - технически реализуемо. Обычным переназначением секторов флеша. И "загрузка кода с одного и того же адреса" - никак этому не мешает.

В 25.06.2022 в 13:18, Segment сказал:

Сейчас все больше микроконтроллеров имеют кеширование исполняемого флеша, оно линейно.

И что с того? Как это мешает переназначению секторов? Не вижу никакой связи...

[adnega 10]

В 25.06.2022 в 12:50, jcxz сказал:

В реальной работе разработчика это обычная ситуация: Работает, работает программист с устройством. Много дней подряд. Перешивает его много раз за день (для несведущих - этот процесс называется "отладка ПО"). За это время могут набежать сотни и тысячи циклов перезаписи.

У меня есть такие устройства, на которых разрабатываю. Самое старое, аж 2014 года. Доработка ведется постоянно, иногда более сотни перепрошивок в день.

До сих пор ничего не затерлось (STM32F407). И вообще, ни разу не видел затертого до дыр STM32.

В 25.06.2022 в 12:50, jcxz сказал:

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

У нас такое исключено - товар только из новых комплектующих.

В 25.06.2022 в 12:50, jcxz сказал:

А в гарантийных обязательствах изготовителя устройства гарантируется например срок службы изделия например >=16 лет.

И что? Сломается он через неделю - вы его по гарантии почините/замените. Вы ж не в космос его отправляете.

Гарантия - это не про "не сломается", а про "у Заказчика в этот период будет рабочее изделие".

В 25.06.2022 в 12:50, jcxz сказал:

PS: Не надо со своей колокольни судить об условиях работы и требованиях к изделиям, которые могут быть о других. Вы этих условий не знаете. И как видно - даже спрогнозировать не можете.  

Просто не раскидываете грабли - и будет ок. Не нужно б/у железо отгружать Заказчику.

В 25.06.2022 в 12:50, jcxz сказал:

PPS: И прошу не отклоняться от изначальной сути вопроса. Вопрос "зачем" - не обсуждается.

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

"Зачем" обсуждать, когда это элементарно делается программно?

В 25.06.2022 в 13:25, jcxz сказал:

это сделано например в SD-картах.

Карты памяти могут перезаписываться пользователем многократно - это их нормальный режим работы.

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

Единственных вариант - это реализация эмуляции eeprom-памяти в МК, для хранения настроек, журнала событий и т.п.

Тут я просто выделяю как можно больше памяти и переписываю ее по кольцу.

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

т.е. рано или поздно счетчик позиций дойдет до исправной области.

[Forger 17]

On 6/25/2022 at 1:25 PM, jcxz said:

Точно так же как это сделано например в SD-картах. Ничего сложного не вижу - технически реализуемо.

Вот только карты такие крайне медленные при случайном доступе. В том же SSD стоит более умный чтоли контроллер с кэшем чудовищного размера и кучей всего полезного (кстати, скоро выйдут SSD в формате карт памяти типа SD, если уже не вышли).

Этот контроллер является узким местом.

Впрочем, никто не мешает при старте заливать код из флэши в ОЗУ достаточного объема и оттуда стартовать. По пути проверять состояние прошивки. Если она битая, заливать резервную копию.

В ответственных изделиях именно так и делают. Особенно военного и уж тем более космического назначения. Там вообще - ТРОИРОВАНИЕ.

[jcxz 184]

В 25.06.2022 в 13:35, adnega сказал:

У меня есть такие устройства, на которых разрабатываю. Самое старое, аж 2014 года. Доработка ведется постоянно, иногда более сотни перепрошивок в день.

До сих пор ничего не затерлось (STM32F407). И вообще, ни разу не видел затертого до дыр STM32.

Я разве писал про "затёрлось"?

Прочитайте что такое "retention time". И для каких условий оно задаётся.

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

 

В 25.06.2022 в 13:35, adnega сказал:

И что? Сломается он через неделю - вы его по гарантии почините/замените.

Может для вас это - нормальная ситуация, но я не считаю такой стиль работы нормальным.

В 25.06.2022 в 13:35, adnega сказал:

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

Единственных вариант

Реальный вариант я уже описал. В первом посте и после повторял.

[adnega 10]

В 25.06.2022 в 14:20, jcxz сказал:

Я разве писал про "затёрлось"?

"Износ" и "затерлось" для меня одна суть.

В 25.06.2022 в 14:20, jcxz сказал:

Прочитайте что такое "retention time". И для каких условий оно задаётся.

Ну, просто не нужно нарушать требования, и тогда производитель МК вам что-то гарантирует.

(интересно, как в таком случае обращаться по гарантии, мол, мой МК вместо 20 лет хранил прошивку всего 19 лет?)

В 25.06.2022 в 14:20, jcxz сказал:

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

На самом деле у меня чаще всего память разбита на три части:

- загрузчик - шьется один раз на заводе;

- приложение - рабочий код основного приложения;

- обновление - шифрованный образ приложения распространяемый свободно.

При обновлении пользователь шьет область "обновление", затем загрузчик проверяет, расшифровывает и перезаписывает обновление в приложение.

При старте изделия проверяется приложение. Если оно битое (CRC32 не совпало), то происходит обновление из области обновлений.

Т.е. у меня как бы две копии приложения. Защищает от окирпичивания в процессе обновления и от сбоя прошивки со временем.

Поскольку загрузчик прошивается однократно, то считаю, что он не подвержен износу и время хранения в нем кода максимальное.

В 25.06.2022 в 14:20, jcxz сказал:

Может для вас это - нормальная ситуация, но я не считаю такой стиль работы нормальным.

Считает калькулятор: если экономически выгоднее менять устройства по гарантии, чем городить супер-неубиваемое более дорогое решение,

то я, не колеблясь, выбираю экономически более выгодный вариант.

PS. Однажды сделал изделие для железной дороги. У них там гарантия 7 лет, и такие же проверочные интервалы.

В изделии использовались SD-карты, а про SDHC я тогда и не слышал. Проблема Заказчика, что изделия проработали более 14 лет и продолжают работать.

Заказчику сложно найти SD (кругом SDHC), и списать сложно, т.к. все работает. Постепенно меняют на новые версии (коих уже 3 поколение),

но и старые еще в строю (в том месяце принести одно на посмотреть). Сделал для себя вывод, что супер-надежность много кому мешает,

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

 

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

На STM32 я за это не переживаю, т.к. за более 10 лет плотной работы с ними проблем не видел.

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

 

Насчет SD-карт, заметил, что в read-only-применениях карты все равно деградируют - увеличивается время считывания сектора, появляются битые сектора.

Насчет жестких дисков, у них есть такой параметр MBTF с какими-то космическими сроками (>100 лет). Это не означает, что диск проработает 114 лет.

[jcxz 184]

В 25.06.2022 в 15:12, adnega сказал:

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

Уже в который раз повторяю - Вы неправильно поняли. Переживаю я о том, что после частых перепрошивок, зашитое и оставленное в работе устройство, через некоторое время потеряет прошивку. Так как сильно уменьшилось "retention time" его flash-и. Сколько уже раз можно повторять??

[adnega 10]

В 25.06.2022 в 15:35, jcxz сказал:

Уже в который раз повторяю - Вы неправильно поняли. Переживаю я о том, что после частых перепрошивок, зашитое и оставленное в работе устройство, через некоторое время потеряет прошивку. Так как уменьшилось "retention time" его flash-и. Сколько уже раз можно повторять??

Есть табличка (для STM32G4), дальнейшие переживания не имеют смысла:

[jcxz 184]

В 25.06.2022 в 15:43, adnega сказал:

Есть табличка (для STM32G4), дальнейшие переживания не имеют смысла:

И что дальше? Я все эти таблицы давно уже видел. Если касательно этой таблицы, то перефразирую вопрос:

Если объём встроенного FLASH в МК позволяет хранить N копий прошивки, то: позволит ли изменение стартового адреса прошивки при отладке ПО увеличить значение для строк "1 kcycle" до значения "1*N kcycle"? Или это значение не изменится, так как в МК уже имеется встроенный механизм выравнивания износа FLASH?

 

Может так вам будет понятнее?