STM32H750 + Ethernet + веб-загрузчик

[jcxz 0]

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

Объяснить человеку, для которого существуют два мнения - его и неправильное, что слово "любое" означает ЛЮБОЕ обращение к флеш, в т.ч. из программы, исполняемой ядром, - это сложно. Извините, я сдаюсь.

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

 

PS: У вас какие-то личные проблемы? Может весеннее обострение чего либо? Или ПМС? Иначе - не понимаю ваших всплесков эмоций.... Личных наездов с моей стороны вроде не было, а с вашей какая неадекватная реакция на меня в каждом сообщении. Я вам на на какую-то мозоль наступил? Чем-то обидел лично?

 

1 час назад, AVI-crak сказал:

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

Так расскажите нам про этот самый бит. Зачем держать в сокровенной тайне? А мы вместе посмеёмся.  

[AHTOXA 0]

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

Записываем программу в ОЗУ, запускаем её, отключаемся. Программа после этого получает доступ к флешь?

Нет, не получает. После того, как был подключён отладчик, и вплоть до отключения питания любые обращения к FLASH приводят к Hard Fault-у. Неужели вы думаете, что в ST не предусмотрели такой простой сценарий?

[jcxz 0]

4 минуты назад, AHTOXA сказал:

Нет, не получает. После того, как был подключён отладчик, и вплоть до отключения питания любые обращения к FLASH приводят к Hard Fault-у.

Ну вот тогда понятно.

Цитата

Неужели вы думаете, что в ST не предусмотрели такой простой сценарий?

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

[AHTOXA 0]

 

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

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

Вся беда в том, что вы высказываете свои предположения в виде безапелляционных утверждений. Если бы вы написали что-нибудь типа "а нельзя ли здесь сделать так..", то, думаю, все бы всё поняли правильно.

Надеюсь, что вы воспримете это сообщение как конструктивную критику, а не как наезд.

[MX_Master 0]

Раз уж мы с RDP Level 1, наконец, разобрались. Предлагаю обсудить очередную интересную задачу..

Предположим, что во время парада планет звёзды сошли криво. И в самый ответственный момент обновления прошивки с устройства убыло питание И теперь у клиента на руках лежит новоиспечённый кирпичик. Как в таком случае минимизировать ущерб и потраченную бухту нервов? 

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

[Сергей Борщ 0]

18 минут назад, MX_Master сказал:

И в самый ответственный момент обновления прошивки с устройства убыло питание И теперь у клиента на руках лежит новоиспечённый кирпичик.

На первой странице было:

В 21.02.2019 в 20:57, Сергей Борщ сказал:

Во встроенной флеши хранить основной и аварийный загрузчик, основной при старте проверяет и распаковывает зашифрованный образ в ОЗУ, если распаковка дает рабочий образ - передает управление ему, если распаковка не удалась - передает управление аварийному загрузчику, который кричит "все пропало, шеф!" и предоставляет веб-морду для заливки рабочего образа

 

[dac 0]

17 hours ago, Darth Vader said:

И, как обычно, мы (или кто-то из команды) в какой-то момент забываем включить в прошивку код, проверяющий и отключающий дебаг  

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

2. прошивка без отключения должна выдавать явное предупреждение при запуске, после прошивки устройства же проверяются?

 

[Arlleex 0]

41 минуту назад, MX_Master сказал:

Предположим, что во время парада планет звёзды сошли криво. И в самый ответственный момент обновления прошивки с устройства убыло питание И теперь у клиента на руках лежит новоиспечённый кирпичик. Как в таком случае минимизировать ущерб и потраченную бухту нервов? 

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

При старте загрузчик проверяет валидность всей прошивки перед передачей ей управления; например, по CRC32. Если прошивка не корректна - переводим управляющие ножки МК в безопасное состояние и бесконечно ожидаем новую прошивку.

[MX_Master 0]

Друзья, видимо, я недостаточно акцентировал внимание на характеристиках встроенной флэшки. Поэтому повторюсь. У нашего STM32H750 всего лишь 1 страница (1 сектор) встроенной флэши размером в 128 Кб. И Всё.

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

Ну и напомню, что в проекте будет внешняя SPI флэшка. Возможно применение батарейки для подпитки RTC и Backup SRAM (4 Кб). Также используется уровень защиты RDP Level 1. Соответственно, содержимое новой и старой прошивки лучше не раскрывать.

Вощем-то, набор инструментов позволяет нам подстраховать процесс перепрошивки. Но этот пазл и всю последовательность я в голове никак не могу собрать.

[jcxz 0]

25 минут назад, MX_Master сказал:

У нашего STM32H750 всего лишь 1 страница (1 сектор) встроенной флэши размером в 128 Кб. И Всё.

Я ещё во 2-м сообщении треда посоветовал Вам поменять МК. Неужто у STM32H7 нет варианта с как минимум 2-я секторами?

[MX_Master 0]

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

Неужто у STM32H7 нет варианта с как минимум 2-я секторами?

Так точно. Есть. Но по цене трёх STM32H750 

[AHTOXA 0]

А чем не подходит вариант, который предложил Сергей Борщ? Во флешке живёт только загрузчик, который при старте разворачивает в ОЗУ зашифрованный образ из внешней SPI флешки.

 

[MX_Master 0]

45 минут назад, AHTOXA сказал:

А чем не подходит вариант, который предложил Сергей Борщ? Во флешке живёт только загрузчик, который при старте разворачивает в ОЗУ зашифрованный образ из внешней SPI флешки.

В этом способе есть несколько отрицательных моментов. Код выполняемый из ОЗУ "может" работать и медленней. В случае возможной запарки, доступ к отладке (или встроенному загрузчику) даст возможность читать из ОЗУ.

Придумал пока только 1 способ подстраховки. Придётся заюзать батарейку и Backup SRAM (4 Кб). Новую шифрованную прошивку надо залить в SPI флэху. Перед началом фатальных махинаций с внутренней флэхой, надо залить в Backup SRAM мини загрузчик. И махнуть адрес загрузки с 0x0800 0000 на начало этого загрузчика. Если все махинации со встроенной флэхой прошли успешно, нужно махнуть адрес загрузки обратно на 0x0800 0000. Если случилось какое ЧП, следующая загрузка начнётся с нашего загрузчика. Он снова зальёт новую прошивку и махнёт адрес загрузки на 0x0800 0000.

Стессна, это всё в теории 

Edited February 24, 2019 by MX_Master

[jcxz 0]

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

Код выполняемый из ОЗУ "может" работать и медленней.

Вы сначала это заметьте. А потом уже бойтесь.  

И если даже всё-таки дошли до такого, что какие-то функции требуют много вычислительных ресурсов, то что мешает расположить их код во FLASH? В открытом виде. Вашему мифическому взломщику от этих кусочков не будет никакой пользы.

 

Цитата

В случае возможной запарки, доступ к отладке (или встроенному загрузчику) даст возможность читать из ОЗУ.

Так сотрите часть своей программы, после того как она выполнена. Например - старт ПО и инициализацию всего, после того как она отработала. Эта часть выполняется быстро и будет очень проблематично успеть за пару миллисекунд подключиться отладчиком. Хотя как тут уже говорили: самое правильное - ставить защиту своей программой (если это возможно в вашем МК). Я так и делал у себя (только не в STM32).

 

Цитата

Придумал пока только 1 способ подстраховки. Придётся заюзать батарейку и Backup SRAM (4 Кб). Новую шифрованную прошивку надо залить в SPI флэху. Перед началом фатальных махинаций с внутренней флэхой, надо залить в Backup SRAM мини загрузчик. И махнуть адрес загрузки с 0x0800 0000 на начало этого загрузчика.

Куда махнуть? и что это даст? Дёрнется сброс во время этих махинаций (из-за той же помехи) и получите тот же кирпич.

[MX_Master 0]

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

Куда махнуть? и что это даст? Дёрнется сброс во время этих махинаций (из-за той же помехи) и получите тот же кирпич.

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

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

Эта часть выполняется быстро и будет очень проблематично успеть за пару миллисекунд подключиться отладчиком.

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