Всем привет.
Для написания собственного бутлоадера, интересует что находится между окончанием таблицы прерываний и адресом входа в основную программу (в частности начало файла startup)?
Начинается с такого:

Это в Keil по крайне мере.
В отладчике проверил, в этот кусок кода попадаем в конце выполнения startup файла.
Мысль одна, что это какая то подготовка регистров ядра. Кто может подсказать, там есть что-то важное или на этот кусок не нужно обращать внимания (не трогать его вообще) и там все всегда стандартно (одинаково)? Если этот код будет дублироваться как в самом загрузчике, так и в основной программе - это нормально?
Или может в проекте с основной программой нужно как то написать scatter файл, чтоб проект вообще компилировался без этой инициализации и startup файла?

Достаточно лишь сделать scatter-файл (скрипт линкера), у которого FLASH начинается с нужного вам адреса и с этим файлом собрать прошивку, которую будете заливать через собственный загрузчик.
Это же можно сделать через настройки проекта.
В своем загрузчике перед передачей управления запретить все прерывания, отключить всю уже включенную периферию и настроить указатель стека SP на новое место, а уже в самом приложении до разрешения прерываний тут же сделать vector remap на новое место.
В принципе, vector remap можно делать и в самом загрузчике.

зы Эта тема с загручиком - старый махровый баян. Изобретать тут уже нечего. Пройдитесь поиском ))

В гугл вбиваем "что такое map-файл" и читаем, читаем, читаем....

PS: Для таких вопросов есть спец. раздел: "Для начинающих".

Меня интересует, нужна ли повторная инициализация startup в основной программе, или от нее нужно избавиться?

Будет лучше, если основную программу предполагать абсолютно независимой программой. Отсюда следует и ответ.
А вот рассчитывать, чтобы эта инициализация в основной проге могла стартовать:
1) либо с произвольных значений регистров периферии (в этом случае в конце бутлоадера не нужно делать деинит использованной в нём периферии, но сама инициализация сложнее);
2) либо с дефолтных после-сбросовых значений регистров периферии (в этом случае в конце бутлоадера нужно сделать деинит всей использованной периферии до дефолтных значений, в этом случае инициализация проще)
- это уже как удобнее.

Категорически обязательна! И она НЕ повторная, поскольку отличается от проекта к проекту.

Можно использовать NVIC_SystemReset
Тогда и деинициализировать ничего не надо.

Как я понял, речь совсем о другом - очередная попытка съэкономить на спичках уменьшить расход флэши.

Конечно.
И упростить.

1) ...и после сброса опять попадаем на бутлоадер. Замкнутый круг

2) Не во всех МК сброс ядра вызывает и сброс периферии. Где-то для общесистемного сброса нужно использовать другие методы.

1. Не верно, так как зависит от программиста
2. Мы говорим о STM32

Ставим маркер в ОЗУ и пролетаем мимо, делов-то.

Правильно товарищ пишет.

Т.е.: если скажем возле устройства сидит программист Вася, и оно в этот момент выполняет сброс, то управление попадает в бутлоадер. А если сидит Петя, то после сброса управление попадает в другое место?


Хммм... Очевидно Вы работали со всеми возможными STM32 и нынешними и даже будущими?
Я бы не высказывался так категорично.

Даже если сбрасывается периферия, то ОЗУ остается.
простейший флаг решает задачу.

Другое дело, что у ядра не обязана быть реализация NVIC_SystemReset

Не зависит. Настоящий программист сначала изучит готовые решения.
А все остальные "программисты" - изобретают велосипеды.

Не совсем так. Если сидит aaarrr, то думаю будет работать.

Нет. Не "делов-то". Вы опять как и предыдущий оратор 90% не договариваете.
1) надо позаботиться чтобы этот маркер не попал в область используемую ROM-бутлоадером;
2) надо не забыть снять этот маркер, перед сбросами из основной программы, после которых нужно войти в бутлоадер;
3) если нужен вход в бутлоадер при любом типе сброса, в том числе неожиданных по WDT или BOR из основного ПО, то маркер нужно снять уже при старте основного ПО и зарезервировать место под него, чтобы оно не использовалось в основной программе.

Настоящий программист даже вопрос такой не будет задавать.

Не всё.
В некоторых МК вообще есть биты управления тактированием некоторыми регионами ОЗУ и при сбросе всей периферии (а не только ядра!) эти биты также могут быть сброшены и содержимое ОЗУ станет непредсказуемым.


Я бы вообще не стал бы доверять девайсу, который работает или нет в зависимости от того кто сидит рядом

Я тому, кто рядом сидит не доверяю. Тем более девайсу.
Иногда для RM делаю исключение.
Хотя вот SEGGER доверяет STM32F072C8 и делает NVIC_SystemReset.

Вы поняли мою мысль

Мысль не понял.
Намёк понял.

Если для кого-то это "90%" не являются очевидными, то ему не стоит пока заниматься написанием загрузчика.


0) надо озаботится достаточной разрядностью маркера, например.

И можно еще пару десятков пунктов добавить, кэп одобрит

Тут вообще, что ни тема, все сплошные намеки

У Вас САМ segger это делает???
Странно... у меня он делает то, что ему указано в разделе "J-Link/J-Trace\Setup\Reset" свойств проекта IAR.
Какой-то он у Вас больно самостоятельный.


То что вопрос задал именно этот "кто-то", видно уже из первого поста.

SEGGER это делает в своём коде для JLink-OB.
Для вызова бутлодера, который обновляет прошивку свою.
А так как код их бутлодера неизвестен, то приходится вызывать системный (DFU) и через него менять прошивку на новую.
Но это совсем другая история.

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

И как он поможет определить, например, был ли вызван сброс из bootloader'а, или из основной части?

Это универсально для многих архитектур. Тем более, как было отмечено, не покажет конкретно откуда сбросили.

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

Стираете первый сектор, но записывайте с конца и будет вам флаг записи во флэш.

P.S. Так как сама тема надуманная, то и ответы такие же.