Перейти к содержанию
    

Что у STM32 после таблицы прерываний?

Всем привет.

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

Начинается с такого:

0x080000C0 F000F802  BL.W     __scatterload (0x080000C8)
0x080000C4 F000F83E  BL.W     __rt_entry (0x08000144)
0x080000C8 A00C      ADR      r0,{pc}+0x34; @0x080000FC
...

Это в Keil по крайне мере.

В отладчике проверил, в этот кусок кода попадаем в конце выполнения startup файла.

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

Или может в проекте с основной программой нужно как то написать scatter файл, чтоб проект вообще компилировался без этой инициализации и startup файла?

Изменено пользователем maxntf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Это же можно сделать через настройки проекта.

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

В принципе, vector remap можно делать и в самом загрузчике.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Будет лучше, если основную программу предполагать абсолютно независимой программой. Отсюда следует и ответ.

А вот рассчитывать, чтобы эта инициализация в основной проге могла стартовать:

1) либо с произвольных значений регистров периферии (в этом случае в конце бутлоадера не нужно делать деинит использованной в нём периферии, но сама инициализация сложнее);

2) либо с дефолтных после-сбросовых значений регистров периферии (в этом случае в конце бутлоадера нужно сделать деинит всей использованной периферии до дефолтных значений, в этом случае инициализация проще)

- это уже как удобнее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно использовать NVIC_SystemReset

Тогда и деинициализировать ничего не надо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно использовать NVIC_SystemReset

Тогда и деинициализировать ничего не надо.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно использовать NVIC_SystemReset

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

Тогда и деинициализировать ничего не надо.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

2. Мы говорим о STM32

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

2. Мы говорим о STM32

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

Я бы не высказывался так категорично.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Даже если сбрасывается периферия, то ОЗУ остается.

простейший флаг решает задачу.

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

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

×
×
  • Создать...