Дык, я с этим и не спорю, в прошлом посте я дал ссылку на большой документ, где это написано.
Вот только это имеет отношение только для случая, если boot загручик был запущен.


Вы не понимате )))
Нету никакого кода, который якобы считывает эти два пина. Это все сделано аппаратно. И происходит это в первые 4 такта проца после сброса.
Это указано в мануале на каждый проц: The boot mode configuration is latched on the 4th rising edge of SYSCLK after a reset. It is up to the user to set boot mode configuration related to the required boot mode.
Даже если бы эти пины опрашивались в неком коде, то даже гипотетически невозможно создать такой код, который бы за 4 такта умудрился проинитить хотя бы стек, настроить пару пинов и прочитать их содержимое


Кстати, вот это только что выяснил: The boot mode configuration is also re-sampled when exiting from Standby mode, на будущее надо учесть!

boot / не-boot - вопрос не в том, что в конце-концов стартует, а в том - какая ОЗУ портится при старте.

Вопрос был как раз именно "в том":

Чудес не бывает, но бывает недостаточно внимательное чтение мануалов



Дык, если сам user-код гадит под себя портит ОЗУ, то все вопросы к этому самому коду!
Но это РЕШАЕМО (способов несколько).

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

Вы не со мной спорите, а с мануалом от ST. Имхо, это бессмысленно

Вопрос не про пользовательский код. А именно про boot-ROM. И в каких случаях и где он портит.


Я не спорю с мануалом. Выдержку из него я привёл выше. В которой указывается, что "8 Kbyte starting from address 0x20000000 are used by the bootloader firmware".
Как там написано, так и читаю. К тому же там сказано про бутлоадер версии v7, а какой у меня - не знаю.

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


А вы остальное почитайте, в частности раздел "Boot configuration".
Ссылку на более полный документ я приводил выше. Там уже расписано про все возможные бут-загручики любых STM32.
В т.ч. указано, какую и где память использует, сколько времени нужно на старт и какие условия необходимы для запуска загрузчика.

Не пойму, к чему этот спор?






Вот еще кое-что полезно для себя нашел, может, тоже кому пригодится:

Empty check
On ХХХХХХ devices only, internal empty check flag is implemented to allow easy programming of the virgin devices by the boot loader. This flag is used when BOOT0 pin is defining Main Flash memory as the target boot space. When the flag is set, the device is considered as empty and System memory (boot loader) is selected instead of the Main Flash as a boot space to allow user to program the Flash memory.

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

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

Сорри за офф ))))

Предположим, что бут-код стартует всегда и выбор режима дальнейшей работы осуществляется программно (тем более что у STM32F042 это именно так). что мешает осуществить эту проверку без стека и переменных? Это же буквально десяток асмовых команд (кстати, латч ножек Boot на 4 такт sysclk какбэ намекает). В общем не буду толочь воду в ступе - на всех виденных мной STM32 содержимое SRAM полностью сохраняется при сбросе, если ножками/фьюзами выбрана загрузка из флеша.

Достаточно стертого вектора reset

Предполагать бессмысленно, все факты описаны в даташитах - выбор места старта выбирается неким аппаратным узлом, который НЕ является частью заводского бутзагрузчика.
Это по сути простейший автомат состояний, который размещен прямо на кристалле, он совсем крохотный, поэтому встроен в каждый STM, отключить его нельзя (а смысл?).
Он лишь, так сказать, "корректирует" вектор сброса перед запуском ядра.


Именно!
Более того, в SRAM судя по всему нет аппаратного сброса, поскольку, судя по даташитам, после подачи питания там "мусор".


Есть такое, вот тут нашел подтверждение:


Но этот флажок реализован не во всех STM32, в "старых" семействах, увы, он не реализован ((

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

Запуск кода из допустимых для данного мк областей памяти - память sram не искажается.
Ресет не искажает память.

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

Бут является аппаратным механизмом, без использования ресурсов ядра и памяти. Но в момент полноценной работы - память stam используется в качестве буфера. Адреса массивов являются аппаратными, изменить их нельзя. Максимальный бардак в памяти получается при загрузке через usb.

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

Действительно, бессмысленно предполагать. Надо тупо залезть дизасмом в бут и посмотреть

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

КАК?
Каким образом смотреть содержимое ядра и адресного пространства мк в режиме явного срабатывания загрузчика по usart???
Вопрос на миллион баксов!!!

Вероятно, имелось ввиду подключиться отладчиком, и смотреть из-под соотв. проги, например, такой: https://www.segger.com/products/debug-probe...er/about-ozone/.
Это вполне реализуемо, если камень не залочен.

Очевидно: подключиться стандартно эмулятором и с помощью него запустить код UART-загрузчика из ROM?
Или что имелось в виду?

Я говорю о том, что в момент аппаратного срабатывания триггера выбора загрузочного интерфейса - всё остальное отключается!!!!. Потому как сам механизм записи в память флеша - не имеет арбитра. Да и всего остального фарша - тоже.

Не понял вопроса. Код бутлодера доступен для чтения всегда (если камень не залочен).


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

Явно слова hardware там не указано, но вы внимательнее почитайте про принцип выбора вектора сброса.
Более того, в даташитах явно указано, после выхода из standby режима повторно производится опрос пинов boot (это указано в даташитах), а уж это явно сделано аппаратно.
Ну, и как минимум то, что управление передается заводскому загрузчику по точно такому же принципу, как и юзер-коду,
наводит на мысль, что выбор вектора сброса производится где-то в недрах камня, про детальную работу которого нигде нет информации.
Если вам удастся найти эту информацию, поделитесь с нами

Это еще почему?
По-мне - как раз существующее исполнение вполне логично.

Так всё-таки: что мешает не срабатывать этот самый триггер, а подключиться как обычно JTAG-ом, найти точку входа в процедуру загрузки по UART (в ROM очевидно) и запустить её ручками?
Может быть конечно, что при подключении JTAG область ROM становится невидимой, но обычно она видна (в тех МК что я видел).

Если камень не залочен, то ВСЕ прекрасно видно, весь камень ))




зы Ради спортивного интереса прям щас принудительно кинул BOOT0 на VDD, подключился через Ozone. Загрузчик тут начинается с 0x1FFFC800 (discovery на базе STM32F072RB, st-link ессно перешит в j-link)
Встроенный бут запускается сразу же после сброса (нажали на кнопку, которая коротит NRST на землю) и тут же останавливается (нужно выбрать режим сброса "Reset & halt").
Т. е. управление СРАЗУ ЖЕ передается в System memory, как и указано в даташите.
Вот картинку сделал:
Нажмите для просмотра прикрепленного файла


Кстати, посмотрел на состояние SRAMдо и после аппаратного сброса: не потерлась.
Кроме, конечно тех частей, к которым обращается сам код.

Теперь осталось только обещанный миллион с AVI-crak стрясти! Все свидетели - он обещал

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

Нет, это - не "программный" ресет, это - сброс всего ядра и вообще всего проца (через модуль отладки).
Кстати, программный сброс у STM сделан так, что формирует фактически как и аппаратый сброс (тянет ножку NRST на землю на несколько мкс).
Отличается программный сброс у STM от полного сброса POR (подали питание) разве лишь тем, что содержимое SRAM сохраняется.
Открывайте мануалы, изучайте. Там все про это расписано. Внимательно читайте. Пусть у ST и не самая лучшая документация, но это там точно описано.

Я же пробовал под отладчиком жать аппаратный сброс (я написал об этом в прошлом посте, читайте внимательнее).
Поведение точно такое же, разве что отладчик подключается лишь сразу после отпускания кнопки сброс.
Но если выбрать режим подключения "Reset & Halt", то проц останавливается сразу же на месте запуска встроенного загрузчика или юзер софта (зависит от BOOT0).

Короче, если вы ВЕРИТЕ в существование какого-то мифического бут-загрузчика в STM, который всегда безусловано запускается, то это - лично ваше дело, вероисповедание - личное дело каждого.
Но коли речь идет про конкретные физические вещи, созданные обычными людьми, то и правила тут работают соответствующие - факты. Факты я привел.
А домыслы и мифы предлагаю оставить вне этой темы

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

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

Мне же лично решение ST в данном случае кажется вполне логичным.


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

Вот именно! Я об этом же и писал - совершенно нелогично. Когда под боком такое мощное ядро.
В ST не дураки сидят - зачем делать то, что можно не делать?
Скорее всего ST хитрит - скрыли этот код инициализации в недокументированную область.

Этот аппаратный узел позволяет вообще не трогать ядро, ничего не трогать.
Т.е. ядро, периферия, тактовые генераторы и т.п. изначально вообще остановлены.
Причины могут быть разные - борьба за потребление, за надежность да и мало еще за что?!

Короче, не нравится решение ST? Нет проблем - рисуйте свой проц и делайте так, как душе угодно


Уфология прям - зеленых человечков никто не видел, но они есть!

Ядро/тактовые генераторы и пр. изначально не остановлены. Иначе пользовательское ПО вообще не могло бы запуститься.


Это всего лишь логика.
Если к примеру на плате Вашего устройства уже стоит МК и вдруг появляется дополнительная необходимость - при включении питания платы (МК) пискнуть в динамик. Вы поставите дополнительную FPGA, на которой будете реализовывать генератор? Или всё-таки задействуете одну из ног существующего МК и напишете простенький цикл в начале ПО?

В режим standby тактирование ядра отключено, но при выходе из этого режима производится повторный опрос входов BOOT, это описано в даташите.
Что говорит о том, что опрос пинов BOOT производится аппаратно, но не программно неким мифическим скрытым загрузчиком. Это факт.

Это всего лишь демагогия. Факты в студию - факты!

Имелось в виду слить дамп памяти встроенного бутлодера и дизассемблировать его. Дабы подтвердить/опровергнуть предположение о программном характере выбора пути загрузки.
Посмотрел бут F030 - обращений к регистру конфигурации не увидел. Указатель стека сразу же указывает в RAM, но вначале достаточно долго RAM не портится - идет куча действий строго на регистрах.

Встроенный загрузчик STM (размещен в System Memory) не участвует в принятии решения кто будет работать, т.к. он сам является частью выбора.
Он запускается после принятия решения. Я лично в этом убедился, о чем выше написал и привел скриншот.

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

Не вижу ничего смешного при работе с фактами, которые описаны в даташитах!


Коли я прав, но моя аргументация вам не нравиться, так приведите свою, основанную на фактах, а не на домыслах и предположениях.


Вы себе придумали некую "религию" и пытаетесь в ней убедить остальных. Подобные действия лишь доказывает, что "верующий" сомневается в своей "вере".


Факт - пины JTAG доступны лишь при разлоченном проце (Level 1 или Level 0). В режиме Level 2 отладка навсегда заблокирована, снять блокировку нельзя.
Факт - на тотально залоченном проце (Level 2) бут-загрузчик при старте НИКОГДА НЕ запускается, о чем указано в датишите.
Факт из даташита (цитирую еще раз):
When readout protection Level2 is activated, STM32 does not boot on system memory in any case and
Bootloader can't be executed (unless jumping to it from Flash user code, all commands are not accessible except Get, GetID, and GetVersion).
Это говорит о том, что узел, определяющий кто может работать а кто нет - вначале ориентируется на Option Bytes и состояние пинов BOOT.
Не так уж и сложно сделать железобетонный автомат на логике, который все это делает без всяких микропрограмм и скрытых бут-загручиков.
Впрочем, как именно это сделано, нигде не описано. А причины просты - дабы не открыть секретную информацию по тому, как вскрыть залоченный проц.

Факт: в даташите указано, что запускается ИЛИ system memory со своим бутзагрузчиком ИЛИ flash memory с вашей прошивкой. ИЛИ/ИЛИ. Никаких других вариантов не указано.
Факт: загрузчик из System Memory запускается безусловно только в случае полностью стертого проца и то не в самых старых семействах ST.
В всех остальных случаях перед запуском бут-загрузчика производится анализ состояния пинов BOOT и в некоторых STM определенных регистров из Option области.

Обратите внимание, я привел факты.


Мы говорим про конкретное семейство МК - STM32. Предлагаю не отвлекаться.

Короче, если найдете хоть какую-то новую информацию по работе узла запуска/загрузки STM, выкладывайте сюда. Со ссылками.

Ошибкой является принимать свою трактовку расплывчатых слова из даташита за факты.
Ну и вообще, даташиты очень часто многое умалчивают. Например даташит на STM32F101 умалчивает о наличии в на кристалле USB Device контроллера и нескольких лишних десятков килобайт FLASH.

Да, мне не нравится отсутствие логики на техническом форуме.
В даташите описано конечное поведение микроконтроллера, а не способ реализации такого поведения. Наличие некой аппаратной схемы, которая там чего-то куда-то переключает в зависимости от состояния ножек и option bytes - это сугубо ваши домыслы, в даташите же ничего на эту тему не сказано.

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

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

Это не говорит абсолютно ни о чем.

Не сложно, главное верить.

А что, возможен вариант И/И? Ну и зачем производителю расписывать свою внутреннюю кухню, если потребителю от этого не холодно и не жарко?

Неправда, причем в данном случае прямо противоречащая даташиту. Вполне определенно сказано, что проверяется адрес 0x08000000 на равенство 0xFFFFFFFF.

Нет. Вы привели цитаты из даташита и придумали им свои трактовки.

Щаз, штаны подтяну и ломанусь искать опровержения вашим выдумкам.

В фантастических книжках, конечно, возможен, но в реальности (в т. ч. в даташитах) пока что только ИЛИ

Если вы утверждаете, что загрузчик из System Memory стартует всегда и безусловно, несмотря на то, что в даташитах указано обратное,
то объясните эту цитату, которая есть в полном даташите на любой STM:


Или вы веруете считаете, что во всех STM существует некий "секретный бут-загрузчик", который нигде не описан и который не имеет никакого отношения к официальному загрузчику из System Memory?
Я правильно понял?

И где же там указано "обратное"?

А что именно вызывает затруднения в понимании? При выходе из Standby фактически происходит полная реинициализация процессора (кроме Backup домена). Видимо при этом отрабатывается ровно та же процедура, что и при PowerOn.

Конечно вы поняли неправильно, для чего вам потребовались значительные усилия.
Повторяю в третий раз:
в даташите абсолютно ничего не сказано про то, как именно реализован выбор варианта загрузки, описан только результат. Ваша святая вера в "секретную схему" ни на чем не основана.

На закуску читаем RM0090:

Мля, да в любом полном даташите на ЛЮБОЙ STM32 в соотв. табличке указаны варианты исключительно ИЛИ:
Нажмите для просмотра прикрепленного файла


Я лично убедился под внешним сторонним отладчиком, что при конфигурации старта из System Memory, запускается системный бут-загрузчик строго с того адреса, где он указан в даташите.
Если же запускается некий "секретный загрузчик" до передачи управления в System Memory или Main Flash, то он не имеет никакого отношения к УСЛОВНО запускаемому загрузчику из System Memory.


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

Однако, как я понял, вы упорно верите в то, что загрузчик из System Memory стартует ВСЕГДА БЕЗУСЛОВНО несмотря на то, что в даташитах указан его УСЛОВНЫЙ старт .
А коли так, то предлагаю на этом поставить точку, ибо иначе это все, просто, перерастет в некую фантастику, религию и т. п.

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

Я убедился путем дизассемблирования, что в STM32F030 в системной памяти нет команд, определяющих вариант загрузки. Но:
1) "секретный загрузчик" может быть и в другом месте
2) В других камнях STM32 может быть по-другому. Как минимум у STM32F042 отличия должны быть.

Это не вопрос веры, это вопрос неверия. У нас нет достоверной информации о том как это реализовано. Может быть так, может быть эдак, может быть еще каким-то третим способом. Но вы упорно настаиваете на одном конкретном варианте, непонятно на каком основании. Аппаратное решение совсем не проще в реализации и уж явно не гибче. Ежели какая-нибудь бага обнаруживается, то проще изменить заливаемый на конвейере код загрузчика, чем вносить изменения в маски.

Я уверен (и Reference Manual на STM32F4xx это подтверждает), что как минимум у ряда контроллеров из семейства STM32 код системной области (не буду называть его загрузчиком дабы избежать путаницы) принимает участие в выборе режима старта.

Алилуйя! Наконец-то мои слова услышаны!
Камень ведет себя именно так, как описано в даташите. Встроенный загрузчик запускается точно также условно, равно как и пользовательский код.
А вы пытались с этим спорить... Смысл?

Ура!


Точно также он может быть лишь в фантазиях того, кто его выдумал


Вот, вы меня уже цитируете

Читайте внимательнее:
Я настаиваю совсем на другом - чтобы вы не путали встроенный штатный бутзагрузчик с неким своим вымышленным "секретным" загрузчиком.


Весьма спорное утверждение - камни на заводе не прошивают, как вам это может показаться. Тестируют кристаллы прямо на пластине, причем, наверняка выборочно.
Бут-загрузчик у STM находится не во FLASH, а в некой ROM, она обходится дешевле FLASH.
Эта ROM не прошивается, а формируется сразу на этапе производства масок для процессов литографии и т. п.
Т.е. для смены версии загрузчика меняется целиком весь кристалл заодно с исправлениями ядра/периферии, а отдельно перешивать уже изготовленные камни никто не будет - это абсолютно невыгодно.

Для примера - если в печатной плате есть некритичный косяк, то такие косяки "накапливают" с другими и выпускают новую версию платы, где эти косяки исправлены ВСЕ ВМЕСТЕ.
Никто не будет по-настоящему серийные платы вручную дорабатывать, т. к. их намного выгоднее списать и сделать новые правильные.
А в случае микросхем зачастую выгоднее выпустить еррату и "собирать косяки" на новую версию камню. Чем толще еррата, тем более скупой производитель процов
Не стоит путать реально мега-массовое про-во со штучными "гаражными" поделками!

Дык, если это указано в даташите на этот камень, то так одно и должно быть. Уверен, что под отладчиком это будет полностью подтверждено. Я с этим не спорил и не спорю ))
Речь-то совсем о другом - о том, что не описано ни в одном официальном даташите и никак не выясняется под отладчиком.
Этот "аппаратный узел" / "секретный загручик" не имеет никакого отношения к штатному загрузчику из System memory, он не является его частью, что подтверждают даташиты и отладчик.
С самого начала именно это я и пытался донести.
Теперь-то, надеюсь, все прояснилось?

Итоговое поведение процессора соответствует даташиту. Как именно это реализовано - по-прежнему неизвестно.

Читайте внимательнее: у STM32F42x это один блок кода.

К счастью, в ST идиотов мало сидят достаточно умные люди, чтобы не пытаться вышеуказанную чушь реализовывать. Потому бутлоадер размещают в самом обычном флеше и прошивают его в процессе производства. Что позволяет не только менять заливаемую версию бутлодера без изменения масок, но и складывать туда Unique ID, калибровки температурного датчика и тактового генератора, уникальные для каждого кристалла. О чем, совершенно не скрываясь, пишут в своих даташитах.

Маску наверно под каждый кристалл переделывают, угу.

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

Вы специалист по мега-массовому производству или из гаража разъяснения даете? Сколько миллионов изделий произвели?

Учебник логики купите. Может поймете, чем "отсутствие доказательства явления" отличается от "доказательства отсутствия явления".

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

Рекомендация почитать учебник - переход на личности? Как все запущено.

Ну и так, чтобы черту подвести. Берем дамп системной области STM32F042F4, смотрим чего там и как. И видим такую замечательную последовательность команд:

И далее:

Комментарии нужны или и так понятно?

Именно - © "Как все запущено": в штатном загрузчике есть команда GO, выполняется по запросу по каналу обмена, из которого шла заливка свежей прошивки.
Вы привели кусок этой команды, выдранный из штатного загрузчика, который без труда можно вычитать. С этим справится любой школьник.
Повторюсь: штатный загрузчик не имеет никакого отношения к некому скрытому аппаратному узлу (или по-вашему некому секретному загрузчику), который определяет порядок запуска кода.

Короче, есть что-нибудь дельное, по теме?