Да ресет тут будет нужен для поддержки встроенного загрузчика от STMicroelectronics. Подтягиваете BOOT0 к 1, даете импульс сброса - все, микроконтроллер начнет хавать прошивку по UART, например. Но я бы не стал впиливать их загрузчик в свое устройство. Достаточно UART-а и никаких reset-ов и GPIO лишних.

Можно и без ресета, но если ваша расчудесная программа (или загрузчик) завинет - будете бежать питание передергивать ?
Про WDG можно не писать.
Естественно в загрузчик можно и через команду попасть.

Да однозначно RST подтяну к ведущему. IWDG также присутствует в некоторых модулях.
Резюмируя, я так понимаю, что любые МК, например DSPIC33 в качестве субведомых (управляется ведомым) также можно шить по UART ведущим? Просто каскадный bootloadr?

Я нашел кучу примеров Bootloader'ов для прошивки по вайфай, USB и SD и т.п. Но не нашел ни одного примера кода как один STM32 шьет другой STM32 тем более Атмегу.
Если есть у кого пример - кусок кода или ссылка будут очень благодарен!
Самое главное что я хотел этой веткой для себя решить - это наличие такой возможности. Соответсвенно она есть и теперь я могу двигаться дальше.
Всем спасибо!

https://electronix.ru/forum/index.php?showtopic=145731

Вам всего-то нужно понять простую мысль:
Вы нашли примеры как прошить от ПК через различные интерфейсы конечный контроллер.

Так вот в вашем случае под ПК нужно понимать ваш первый МК с флеш-картой как диском-хранилищем.
Т.е. в первом МК должен быть функционал прошивальщика через УАРТ ведомых МК.

А уж какие вы примените алгоритмы и протоколы - это уже детали реализации.

Спасибо огромное!



Вот теперь всё более менее становится на свои места! СПАСИБО!!!

это подходит для 128 меги. А для стм32 - вполне можно сделать чтоб сам себя шил. единственный трабл - динамические адреса.

(круглый)

О чем речь?

Да это (круглый) опять отлаживает свой ПД ( приход дури ) регулятор. Видать словил...

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

(круглый)

Сообщение отредактировал kolobok0 - May 25 2018, 21:02

Система с кучей STM32 в том числе F7 имеет право на жизнь, и отдельный F7 отвечающий за библиотеки прошивки это тоже нормально. Но в определенных случаях. Например это удаленная система без непосредственного доступа оператора с плохим каналом связи. Т.е прошивка для апгреда заливается медленно и печально, часами или неделями, с обрывами связи. Процессор-менеджер фирмвари этим и занимается. Когда прошивка залита во внешний флешь, проверены ее чексуммы и соответствие акуальной версии харда остальных процессоров, то планируется действия по накатыванию фирмвари в безопасный для техпроцесса период. При этом во флеши менеджера прошивок лежит как минимум две копии фирмвари, в том числе и для даунгрейда в случае проблем. Т.е если вылезит баг при накате прошивки то всегда можно быстро откатиться без передачи новой-старой фирмвари по ненадежному каналу связи. Ну а мультипроцессороность позволяет функционировать управляющему блоку даже при неудачной прошивке. Т.е новая фирмварь вводится в опытную эксплуатацию в режиме надзора без включения в управляющий контур и только после некоторого пробного периода управление переключается на нее. Менеджер фирмвари также может принимать, хранить и высылать журнал эксплуатации системы, журналы срабатывания ватчдогов, трапов и ловушек подчиненных систем итд. Возможен спец-вариант принудительного наката дефолтных прошивок по срабатыванию ватчдога всей системы низкого уровня на "мелком 8-битном процессоре" но с этим надо очень осторожно чтобы не крашнуть систему при проблемах питания. Самоапдейт менеджера фирмвари тоже возможен, но это очень особый случай типа частичной порчи флеша от длительной эксплуатации. Или если эта вся система расположена совсем не на родной планете....
Это все из области ультранадежных дублированных управляющих систем.

Вот только вопрос: а место ли STM32 в этой области?


Совершенно непонятно.... В чём проблема чтобы STM32 "шить сам себя"? Что такое "позднее связывание адресов" и на кой оно?


Конечно возможно. На прошлой работе работе мы много лет все изделия строили по такой схеме (и сейчас их у заказчиков функционируют десятки если не сотни тысяч и обновляются по необходимости). Мы сделали возможность обновления через любой рабочий интерфейс (устройства имеют несколько их разных, в зависимости от аппаратного исполнения): UART, оптопорт, RS-485, CAN, Ethernet, радиоканал, ZigBee, GSM, PLC - обновляться могут через любой из них. Обновление безопасное: прошивка сначала полностью скачивается во внутреннюю энергонезависимую память (рабочим ПО), потом прошивается во флешь программ (бутлоадером). Эти устройства как правило имели в своём составе кроме главного МК несколько программируемых модулей (GSM, ZigBee, радиомодуль, PLC, ...) и для всех из них возможно обновление их внутренней прошивки (для этого каждый сделан с бутлоадером, для обеспечения безопасного обновления если оно идёт по каналу, который поднят на данном модуле).
В большинстве систем наши устройства работали группами с ретрансляцией между устройствами. Например: один внешний канал для связи с центром - GSM на одно из устройств, остальные устройства в группе подключаются к устройству с GSM через ZigBee. Естественно все эти устройства в ZigBee видны из центра и их любой адресно можно перешить. Также делали системы с резервированием канала к центру (в сети ZigBee два узла с GSM; или GSM и Ethernet).


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

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

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


В ОЗУ исполняемый бут? А если питание сбросится во время обновления бута? ИМХО должно быть два бута для действительно безопасного обновления самого бутлоадера.

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

1. Правильно ли я полагаю, что в ОЗУ Вы копируете код (и обработчики исключений) лишь для того, чтобы не потерять возможные прерывания и события при остановке CPU при стирании или программировании Flash?
2. Копии загрузчиков хранятся в разных секторах Flash и не пересекаются, правильно понимаю? Иначе при стирании одного сектора обновляемого загрузчика, можно зацепить активный и при сбросе питания оба загрузчика будут неработоспособными.
3. Тогда есть все-таки один основной механизм, который никогда не обновляется - в начале Flash смотрится какая-то переменная, показывающая, какой из загрузчиков активен, копирует в ОЗУ содержимое Flash региона нужного загрузчика и все его обработчики прерываний, а потом переходит на загрузчик? Загрузчик уже сам понимает что дальше делать - обновлять кого-то или переходить на приложение. Исходя из этого можно предположить, что регионов в памяти у Вас 3: первый как раз навеки-вечно зашитый механизм просмотра и запуска нужного бута, второй - основной бут, третий - резервный бут (копия, как удобно). И располагаются они в разных секторах Flash: первый обязательно в начале, второй и третий (загрузчики) - где удобно не в одном секторе с первым.
Так? Ну вернее я так вижу, как бы сделал я (на беглый взгляд).

Сообщение отредактировал Arlleex - May 30 2018, 10:22