Arlleex 311 February 26 Posted February 26 · Report post 10 минут назад, jcxz сказал: А если таких страниц будет - с 0-й по (P-2)-ю? Вы все эти страницы запишете по 2 раза. А - так ресурс флешки, насколько я знаю, тратится только при стирании. А время записи ничтожно мало по сравнению со стиранием. Ну запишу еще раз, да. 13 минут назад, jcxz сказал: И вы уверены - что запись невозможна если ECC есть? По моим экспериментам - запись проходит нормально, только потом читается мусор из-за неверного ECC-контроля. Но это же не мешает писать поверх. Это я говорил про флешку даже без ECC в STM. Попытка записать не в стертое слово сулит выдачей флага ошибки записи + никакого влияния на ячейку памяти. 15 минут назад, jcxz сказал: По моим экспериментам - запись проходит нормально, только потом читается мусор из-за неверного ECC-контроля. Но это же не мешает писать поверх. И на кой мне мусор из-за неправильного ECC-контроля? Quote Share this post Link to post Share on other sites More sharing options...
jcxz 342 February 26 Posted February 26 · Report post 25 минут назад, Arlleex сказал: А - так ресурс флешки, насколько я знаю, тратится только при стирании. х.з. В даташите написано: Цитата Data Retention Time, Logical Sector (t_RETL) 20 years; Max. 100 erase/program cycles Что означает "erase/program cycles"? Стирание/запись как один цикл? Или erase + program cycles? Не берусь гадать - Хрустальный шар утерян. Да, кстати - тут кто-то писал про "100K циклов" у каких-то МК. А тут мы видим всего 100. Без К. Так что экономия ресурса - важна однозначно. 25 минут назад, Arlleex сказал: А время записи ничтожно мало по сравнению со стиранием. Откуда тапки данные? Открываем мануал на XMC4xxx, читаем: Erase Time per 256 Kbyte Sector = 5.5s max Program time per page = 11+5.5 ms max (это со включённой опцией "Program Verify feature detects weak bits") Считаем время полной записи сектора = (.011+.0055)*1024 = 16.896 сек Т.е. - время программирования в 3 раза больше времени стирания. Посчитаем общее суммарное максимальное время стирания+программирования прошивки размером со всю флешь (2M): (5.5+(.011+.0055)*1024)*2048/256 = ~180 сек = ~3 минуты! (точнее - даже больше, так как не все сектора - 256К, есть мельче, а для них ещё хуже картина; но считать точнее лень) Это конечно максимальное время, но всё-же, всё-же... 25 минут назад, Arlleex сказал: Ну запишу еще раз, да. Вместо 3-х минут - 6??? Юзер повесится ждать. Quote Share this post Link to post Share on other sites More sharing options...
Arlleex 311 February 26 Posted February 26 · Report post STM32F407: Время стирания: 0.5с * 4 + 1.1с + 15 * 2 = 33.1с. А если стирать разово (Mass Erase), то время стирания 16с. Время записи (при кол-ве циклов стирания не превышающее 100к циклов): 16мкс на каждые 32 бита (100мкс максимум когда флешка затерта до дыр). Даже если взять самый наихудший случай 100мкс, получаем для 2МБ-флешки МК время программирования 100мкс * 2МБ / (4 байта на слово) = 52с. Т.е. на посекторное стирание + программирование всей 2МБ флеш уйдет 1 минута 25 секунд. Если применить массовое стирание и потом программировать, время займет 1 минута 8 секунд. Скажите, пожалуйста, как поможет Ваш способ в МК, в котором нельзя дописывать в нестертое слово внутри сектора, или если флеш разделена на секторы, но сектора не состоят из страниц? В частности, как Вы видете преимущества своего алгоритма на STM32F4? Цитата Да, кстати - тут кто-то писал про "100K циклов" у каких-то МК. А тут мы видим всего 100. Без К. Так что экономия ресурса - важна однозначно. Тогда это лишь личный недостаток XMC - крайне хилый ресурс флеш, отсюда и все фишки/плюшки в виде тех самых "особенностей", позволяющих дописывать/контролировать и т.д. Разные подходы. Quote Share this post Link to post Share on other sites More sharing options...
jcxz 342 February 26 Posted February 26 · Report post 50 минут назад, Arlleex сказал: Т.е. на посекторное стирание + программирование всей 2МБ флеш уйдет 1 минута 25 секунд. Ну вот. И это - при напряжении пиатния = 3.3V. А если ниже - то может быть в 2 раза дольше. Т.е. - примерно то же самое. И к тому-же - для XMC я ещё добавил опцию контроля слабых бит (в STM аналога не имеется ) А она тоже время добавляет. 50 минут назад, Arlleex сказал: Если применить массовое стирание и потом программировать, время займет 1 минута 8 секунд. Это с шансом превратиться в кирпич? нет уж - и даром не нужно. 50 минут назад, Arlleex сказал: Скажите, пожалуйста, как поможет Ваш способ в МК, в котором нельзя дописывать в нестертое слово внутри сектора, или если флеш разделена на секторы, но сектора не состоят из страниц? В частности, как Вы видете преимущества своего алгоритма на STM32F4? Преимущество перед чем? Вы так и не объяснили - как применить ваш способ если размер сектора > размера доступного ОЗУ? 50 минут назад, Arlleex сказал: Тогда это лишь личный недостаток XMC - крайне хилый ресурс флеш, отсюда и все фишки/плюшки в виде тех самых "особенностей", позволяющих дописывать/контролировать и т.д. Разные подходы. Или более жёсткий контроль процесса. Да и в чём именно недостаток? Я взял самый быстрый способ стирания - чтобы посчитать время стирания самым быстрым образом (писал выше). Если стирать секторами не 256К, а секторами 64K то количество циклов увеличивается в 10 раз - до 1000 при 20 годах хранения и при макс.температуре +110°C. Но немного дольше будет идти стирание. Смотрим даташит для STM32F429 для аналогичных условий: те же 1000 циклов при чуть более низкой макс.температуре +105°C и всего лишь 10 лет хранения. Получается - если у XMC "хилый ресурс флеши", то у STM32F429 он ещё в 2 раза хилее. Не находите? STM32 уже 10 лет как потеряет заряд ячеек, а XMC будет продолжать работать и работать. А если программа будет контролировать разряд ячеек через соответствующие статусные биты и подзаряжать их - так и вообще 100 лет пропашет! PS: Да и вообще - не МК выбирался для процедуры обновления FW. Это было бы странно. Процедура делалась под конкретный МК. Потому - нет смысла обсуждать "почему именно такой МК". Quote Share this post Link to post Share on other sites More sharing options...
Arlleex 311 February 26 Posted February 26 · Report post 33 минуты назад, jcxz сказал: Преимущество перед чем? Преимущество перед алгоритмами без принудительного подсчета/учета нужных и не нужных секторов для обновления. Цитата Вы так и не объяснили - как применить ваш способ если размер сектора > размера доступного ОЗУ? 1. Принял по каналу связи 128 байт куска прошивки + некая служебная инфа, позволяющая определить, куда писать (по какому адресу флешки). 2. Циклически сверяю записанное по нужному адресу во флешке с тем, что лежит в буфере. Если совпадает, ок. Если не совпадает, рассчитываю адрес границы активного сектора стирания флеш, и отправляю это в ответе хосту. 3. Хост видит адрес в ответе, запихивает следующие 128 байт в буфер канала связи, отправляет. Т.е. МК управляет процессом, передавая либо нарастающую позицию записи, либо откатывая на ближайшую границу, с которой можно безопасно перешить кусок прошивки, если в процессе что-то похерилось. Например, прошивка занимает 5 секторов. Принимая прошивку, обнаружил, что первых 3 сектора совпадают с тем, что реально прошито во флешке МК. Где-то в середине 4-го сектора обнаружил расхождения, и если очередное слово позволяет записать его поверх старых данных (в STM это может быть, если слово имеет значение 1 во всех битах), то пишу поверх. Если не позволяет - отправляю статусный ответ хосту, мол, давай еще раз кусок, начиная с начала смещения сектора 4. Если где-то при стирании/прошивке сбойнуло питание - ничего страшного, процесс начнется сначала, ничего лишний раз не сотрется и не перезапишется. В любом случае, запоротый любым способом сектор придется стирать. В случае шифровки/дешифровки "налету" - аналогично, но размер ОЗУ под очередной кусок прошивки, разумеется, должен быть расчитан на хранение 1 блока при блочном шифровании + буфер на расшифрованные данные. Но размер блока != размеру всего файла прошивки. 33 минуты назад, jcxz сказал: Смотрим даташит для STM32F429 для аналогичных условий: те же 1000 циклов при чуть более низкой макс.температуре +105°C и всего лишь 10 лет хранения. А микроконтроллеры в 99.999% задач работают при +110°C? Что-то мне подсказывает, что если оно так, то в консерватории надо что-то менять, ибо я даже такого нагрева мощных силовых компонентов стараюсь никогда не допускать. А если и планируется облет Венеры, то есть микроконтроллеры, работающие > 200°C, что там с ресурсом флешки, правда, не знаю/не интересовался. Quote Share this post Link to post Share on other sites More sharing options...
Arlleex 311 February 26 Posted February 26 · Report post 28 минут назад, jcxz сказал: Получается - если у XMC "хилый ресурс флеши", то у STM32F429 он ещё в 2 раза хилее. Не находите? Не нахожу. Ибо 100 циклов стирания против 10 000 минимум у STM однозначно наводит на мысль, что после 1000 перепрошивок XMC не факт, что флешка не продырявится настолько, что не позволит даже запустить процедуру усиления битов в ее собственной флешке посредством считывания и записи. А STM-ке будет пофигу. И насколько я понимаю, 10 лет - это время удержания с момента последнего программирования. Quote Share this post Link to post Share on other sites More sharing options...
VladislavS 46 February 26 Posted February 26 · Report post 3 часа назад, jcxz сказал: Юзер повесится ждать У вас же там всё само шьётся в моменты пропадания питания. 😁 Quote Share this post Link to post Share on other sites More sharing options...
jcxz 342 February 26 Posted February 26 · Report post 1 час назад, Arlleex сказал: В случае шифровки/дешифровки "налету" - аналогично, но размер ОЗУ под очередной кусок прошивки, разумеется, должен быть расчитан на хранение 1 блока при блочном шифровании + буфер на расшифрованные данные. Но размер блока != размеру всего файла прошивки. У меня прошивка не от хоста принимается, а читается из SPI-флешки. И зашифрована. И как именно предлагаете шифровать? Независимыми кусками? А в чём преимущество шифрования кусками перед шифрованием всего образа прошивки? 1 час назад, Arlleex сказал: А микроконтроллеры в 99.999% задач работают при +110°C? Что-то мне подсказывает, что если оно так, то в консерватории надо что-то менять, ибо я даже такого нагрева мощных силовых компонентов стараюсь никогда не допускать. Вы - может да. А у нас был заказчик, у которого счётчик стоял под крышей какого-то сарая, находящегося в тундре. За полярным кругом. И когда там случился полярный день - даже корпус счётчика потёк (пластиковый). Так как оказалось, что в сарае без вентиляции под круглосуточными лучами солнца, быстро наступает сауна. А температура - под 100-ку растёт. 🔥 И долго держится так. Весь полярный день. И это обычный счётчик э/э без всяких силовых компонентов. Quote Share this post Link to post Share on other sites More sharing options...
Arlleex 311 February 26 Posted February 26 · Report post 4 минуты назад, jcxz сказал: И как именно предлагаете шифровать? Независимыми кусками? А в чём преимущество шифрования кусками перед шифрованием всего образа прошивки? Ну шифрование (блочное которое) оперирует минимальным куском памяти - блоком. А дальше все зависит от алгоритмов шифрования: есть способы работать с каждым блоком независимо от предыдущих блоков. А есть, где нужно хранить текущий и предыдущий блоки, например. Преимущество, разумеется, в том, что требования к ОЗУ становятся сопоставимыми с любыми 8-битными микроконтроллерами. 1 Quote Share this post Link to post Share on other sites More sharing options...
jcxz 342 February 26 Posted February 26 · Report post 7 минут назад, Arlleex сказал: Ну шифрование (блочное которое) оперирует минимальным куском памяти - блоком. А дальше все зависит от алгоритмов шифрования: есть способы работать с каждым блоком независимо от предыдущих блоков. А есть, где нужно хранить текущий и предыдущий блоки, например. Преимущество, разумеется, в том, что требования к ОЗУ становятся сопоставимыми с любыми 8-битными микроконтроллерами. Про шифрование я знаю достаточно. Вот вы мне объясните - как именно зашифровать этот самый блок так, чтобы его зашифрованный образ имел другое бинарное значение, чем при предыдущем шифровании, даже если шифруемые данные не изменились? Для этого придётся перед таким блоком вставить случайное значение. Перед каждым блоком. И сохранить потом в шифруемом образе. И тут возникает проблема с некратностью уже полученных кусков размеру блока шифра. Да и главное - зачем это всё??? Уже который раз спрашиваю - зачем все эти усложнения, если мой вариант проще? Какой смысл? Quote Share this post Link to post Share on other sites More sharing options...
Arlleex 311 February 26 Posted February 26 · Report post 1 минуту назад, jcxz сказал: Про шифрование я знаю достаточно. Вот вы мне объясните - как именно зашифровать этот самый блок так, чтобы его зашифрованный образ имел другое бинарное значение, чем при предыдущем шифровании, даже если шифруемые данные не изменились? Для этого придётся перед таким блоком вставить случайное значение... А почему его (вектор) нельзя формировать на основе расшифрованных данных предыдущего блока? Quote Share this post Link to post Share on other sites More sharing options...
jcxz 342 February 26 Posted February 26 · Report post 7 минут назад, Arlleex сказал: А почему его (вектор) нельзя формировать на основе расшифрованных данных предыдущего блока? У меня так сейчас и делается. И именно поэтому - я прохожу весь цикл дешифровки всего образа. И тогда случайное данное нужно только одно. И хеш - только один на весь файл. У меня AES-CBC для всего образа + заголовок с хешем. Но вы же как я понял предлагаете разбить образ на куски, шифруемые независимо? И с независимыми хешами? Quote Share this post Link to post Share on other sites More sharing options...
Arlleex 311 February 26 Posted February 26 · Report post 25 минут назад, jcxz сказал: Но вы же как я понял предлагаете разбить образ на куски, шифруемые независимо? И с независимыми хешами? Изначально вопрос возник к этому: 9 часов назад, jcxz сказал: Кроме того - проще, когда у вас образ не шифрованный. А у меня - образ шифрованный AES256. И большой - ОЗУ на весь образ не хватит. А значит - откатиться всего лишь до границы сектора не получится. Нужно запускать процесс чтения/дешифровки от самого начала. А именно к выделенному жирным. Зачем для расшифровки нужен большой объем ОЗУ на весь образ? Я не предлагаю шифровать блоки независимо (хотя это тоже неплохой вариант). Я предлагаю шифровать блоки в режиме последовательного сцепления, и ключ для следующего блока извлекать из расшифрованных данных предыдущего (не обязательно хранить ключ в непосредственном виде в куске расшифрованных данных - достаточно посчитать их хэш). Разве это требует наличия ОЗУ, достаточного для хранения всего образа? Quote Share this post Link to post Share on other sites More sharing options...
jcxz 342 February 26 Posted February 26 · Report post 10 минут назад, Arlleex сказал: Разве это требует наличия ОЗУ, достаточного для хранения всего образа? Этого требует ваше предложение "откатиться назад до границы сектора". А значит - нужно хранить окно дешифрованного образа размером == как минимум размеру сектора. А лучше - весь образ. AES-CBC позволяет дешифровать только в одном направлении. Никаких "откатов". Считайте, что данные читаются с устройства с последовательным доступом, а не произвольным. Quote Share this post Link to post Share on other sites More sharing options...
x893 78 February 26 Posted February 26 · Report post Когда то в детстве делал блоками, с шифрацией, передача от GPRS до Ethernet/WiFi. За 10-15 лет ни разу флэш до дыр не затёрлась. Quote Share this post Link to post Share on other sites More sharing options...
