Да ладно??! А код boot-ROM, выполняемый после сброса, где стек и рабочие переменные размещает?

В STM32 SRAM не страдает от сброса (кроме, разумеется, сброса от передергивания питания, после которого там всегда будет "мусор").
STM32 RAM behavior after soft-reset


зы Помню, что как-то давно я все недоумевал, зачем в STM32 есть boot-режим старта прямо из ОЗУ (соотв. ремап вектора сброса на начало ОЗУ)? ...

Да ладно?!! Они умудрились написать код чисто на регистрах и без использования стека??? Прямо чудеса чудесатые какие-то рассказываете.....
Или они стек boot-ROM-а научились размещать в облаке?

Вы ничего не путаете?

В STM32 есть два спец пина BOOT0 и BOOT1, оменно они определяют кто будет запускаться при старте проца:
user-код (User Flash memory), boot-загручик (System memory), ОЗУ или еще что-то (например, в "толстых" камнях).
Опрос этих пинов производится ядром (или узлом, который отвечает за выбор области загрузки) в течение нескольких тактов после сброса.
Но даже в случае безусловного использования бут-загручика можно выяснить области ОЗУ, которые он использует. А используют они совсем небольшую часть ОЗУ.
Это не секретная информация Все есть в соотв. мануалах ))

Еще раз: BOOT-загрузчик в STM32 НЕ стартует безусловно.
Более того, в тотально залоченном состоянии бут вообще невозможно запустить (разве что прочитать его версию):
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).


Может, вы путаете STM32 с другими камнями (которые без своей FLASH), где BOOT стартует ВСЕГДА после сброса?

В AN2606 в Table 66. STM32F42xxx/43xxx configuration in system memory boot mode указано, что 8 Kbyte starting from address 0x20000000 are used by the bootloader firmware.
И эта область указана как Common to all bootloaders.
Также видно, что указатель стека из вектора сброса из таблицы векторов прерываний в ROM по адресу 0x1FFF0000 (из STM32F429 который у меня сейчас на столе) указывает на адрес 0x20002318 опять-же - внутри этих 8КБ.
Вот именно этот код, который считывает BOOT-пины и определяет куда передать управление (и возможно что-то ещё делает), видимо и находится по адресу, на который указывает вектор сброса из 0x1FFF0000.

PS: Не посчитал однако... 0x20002318 - это ведь уже за пределами 8КБ. Странно....
Опять-же - в AN2606 говорится про Bootloader V7.x. А какая у моего версия - не знаю.

Дык, я с этим и не спорю, в прошлом посте я дал ссылку на большой документ, где это написано.
Вот только это имеет отношение только для случая, если 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

Сообщение отредактировал LightElf - Aug 3 2017, 09:31

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


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


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


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

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

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

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

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

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