Самозагрузчик Опции

[inventor]

Подскажите как правильно сделать вот что:

имеется какой то прибор с SD картой на проце STM32
я хочу сделать для пользователя возможность самому менять прошивку.
делал такие вещи для других процов,
с ST возникли некоторые вопросы.

предположим - нужно поменять прошивку прибора,
саму прошивку - бинарник заливаю в корень SD карты.
при включении питания маленькая программа, loader смотрит:
есть ли файл с определенным именем на SD и если есть, то
записывает его в определенный раздел внутренней flash памяти
далее после того как успешно записал бинарник на flash,
стирает его на SD карте. - передает ему управление.
если файла bin нет - то loader просто передает управление программе.

саму программу Loader я хочу разместить
по адресу Flash 0x08000000
а рабочая прошивка, предположим, будет работать с адреса 0x08001000
после того, как бинарник записан по адресу 0x08001000
как мне LOADER - ом передать ему управление?

[KRS]

после того, как бинарник записан по адресу 0x08001000
как мне LOADER - ом передать ему управление?

Самый лучший способ IMHO - сделать хардварный reset с помощью watchdog!
лоадер уже не обнаружит прошивку и передаст управление...

Но есть еще нюанс - для того что бы лоадеру обнаружить файл на SD, необходимо частично проинитить периферию..., а передавать управление основной программе после этого не хорошо!
Я ставлю метку в озу по определенному адресу (типа 0x55AAAA55) и если лоадер ее обнаруживает, то стирает и передает управление основной программе (установив адрес таблицы прерываний кончено)

[inventor]

Самый лучший способ IMHO - сделать хардварный reset с помощью watchdog!
лоадер уже не обнаружит прошивку и передаст управление...

Но есть еще нюанс - для того что бы лоадеру обнаружить файл на SD, необходимо частично проинитить периферию..., а передавать управление основной программе после этого не хорошо!
Я ставлю метку в озу по определенному адресу (типа 0x55AAAA55) и если лоадер ее обнаруживает, то стирает и передает управление основной программе (установив адрес таблицы прерываний кончено)

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

[Непомнящий Евген...]

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

Вся прошивка в целом линкуется с таким скриптом линкера, чтобы осталось пустое место под загрузчик. При этом вектора прошивки будут сдвинуты. Скажем на 0x8001000 - это зависит от размера загрузчика.

Есть такой регистр - VTOR, который задает положение таблицы векторов
Соответственно в загрузчике перед стартом прошивки его надо скорректировать, выставить стек и перейти по адресу сброса

Код

#define PO_START 0x8001000
SCB->VTOR = PO_START;
__set_MSP(*(uint32_t*)PO_START);
__DMB();

typedef void (* pf)();
(*((pf*)(PO_START+4)))();

[inventor]

то есть я делаю в файле линкера для прошивки исправления:
define symbol __ICFEDIT_intvec_start__ = 0x08001000;
define symbol __ICFEDIT_region_ROM_start__ = 0x08001000;
про компиляции программы моя программа и векторы должны начинаться с адреса 0x08001000

теперь в лоадере я должен передать управление по новому адресу вектора сброса: 0x08001000
правильно я понял?

вернее вектор старта + 4, там вроде в начале адрес стека идет

Сообщение отредактировал IgorKossak - Apr 7 2016, 18:33

Причина редактирования: бездумное цитирование

[jcxz]

саму программу Loader я хочу разместить
по адресу Flash 0x08000000
а рабочая прошивка, предположим, будет работать с адреса 0x08001000
после того, как бинарник записан по адресу 0x08001000
как мне LOADER - ом передать ему управление?

В 0x1000 байт не впихнёте работу с файловой системой однозначно. Чтобы загрузчик был маленький, нужно работу с ФС вынести в основное ПО.
Например: основное ПО обнаружив файл с новой прошивкой, формирует в ОЗУ информацию о цепочке кластеров файла прошивки и ставит флаг наличия. Дальше - перегружается (WDT). Дальше - загрузчик видит флаг, считывает прошивку из цепочки кластеров и шьёт её во флеш программ. Стартует новое ПО. Новое ПО, видя что обновилось, стирает исходный файл прошивки. Всё.
Если нужно чтобы операция обновления ПО была устойчива к сбоям питания, то флаг и инфу о цепочку кластеров нужно сохранять в энергонезависимой памяти.
Как передать управление из загрузчика в основное ПО тут уже 100500 раз обсуждалось и не ранее чем позавчера очередной раз. Учитесь искать.

[KRS]

вернее вектор старта + 4, там вроде в начале адрес стека идет

да! и стек надо тоже проинитить
у меня такой код, но это для LPC и IAR (просто у IAR в r1 = 0x1000 после присваивания VTOR)

Код

        VTOR = (unsigned)0x1000;
        asm ("ldm r1, {r0,r1}\n"
             "mov r13, r0\n"
             "mov r15, r1");
        while(1);

[inventor]

В 0x1000 байт не впихнёте работу с файловой системой однозначно.

а 4 k не влезет но
в 22 киболайт вполне влезает.
с рюшками, uart для отладки и светодиодами

[KnightIgor]

имеется какой то прибор с SD картой на проце STM32
я хочу сделать для пользователя возможность самому менять прошивку.

У меня есть такой загрузчик. Ему требуется примерно 12K флэша. Я зарезервировал 16К, то есть, приложение компилируется так, чтобы начинаться с 16К.
Файловая система на FatFS, с которой выброшено все, кроме чтения (файл прошивки я не удаляю). Есть варианты для SPI и SDIO доступа к карте.
Если при старте карта и файл с определенным именем на ней обнаружены, загрузчик считывает версию образа и сравнивает с текущей версией прошивки. Прошивка для этого содержит соответствующие поля, которые как данные расположены непосредственно за таблицей векторов. Загрузчик, конечно, знает, что и как искать. Если на карте новая версия, производится запись образа во флэш и его запуск. Во всех остальных случаях загрузчик запускает имеющуюся прошивку сразу.

[romas2010]

Подскажите как правильно сделать вот что:
.........
саму программу Loader я хочу разместить
по адресу Flash 0x08000000
а рабочая прошивка, предположим, будет работать с адреса 0x08001000
после того, как бинарник записан по адресу 0x08001000
как мне LOADER - ом передать ему управление?

1) делаете 2 отдельных проекта-загрузчика и основной программы. В каждом проекте задаете свой стартовый адрес (меню keil project->options for target->IROM1),чтобы компилятор генерировал код с данного адреса
2) в код загрузчика добавляете функцию

Код

__asm void run_main_programm()
{
     mov32 r0,#MY_PROGRAMM_START_ADRESS
     ldr r1,[r0]
     mov sp,r1
     ldr pc,[r0,#4]
}

3) прошили, выход из загрузчика

Код

   VTOR=MY_PROGRAM_START_ADRESS;
   run_main_programm();

перед присваиванием VTOR запрещаем прерывания всей используемой в загрузчике периферии+еще запрещаем их в контролеере NVIC

Ну вот собственно и все...не забудьте закоментировать в функции system_init() в коде основной программы строку типа VTOR=FLASH_BASE_ADDRESS, потому как вы уже ему присвоили свою таблицу в коде загрузчика

[x893]

У меня есть такой загрузчик. Ему требуется примерно 12K флэша. Я зарезервировал 16К, то есть, приложение компилируется так, чтобы начинаться с 16К.
Файловая система на FatFS, с которой выброшено все, кроме чтения (файл прошивки я не удаляю). Есть варианты для SPI и SDIO доступа к карте.
Если при старте карта и файл с определенным именем на ней обнаружены, загрузчик считывает версию образа и сравнивает с текущей версией прошивки. Прошивка для этого содержит соответствующие поля, которые как данные расположены непосредственно за таблицей векторов. Загрузчик, конечно, знает, что и как искать. Если на карте новая версия, производится запись образа во флэш и его запуск. Во всех остальных случаях загрузчик запускает имеющуюся прошивку сразу.

Вот бы его на github'е увидеть !

[kolobok0]

У меня есть такой загрузчик...

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

благо флэша - как у дурака махорки

как то так
(круглый)

Сообщение отредактировал kolobok0 - Apr 7 2016, 21:07

[Непомнящий Евген...]

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

благо флэша - как у дурака махорки

Гм, т.е. вы сделали dll на МК. Главный вопрос - зачем ?

И еще кучка вопросов по реализации, интересно
* как тестировали? По идее надо проверять каждую версию с каждым набором версий других модулей
* как линковали? Каждый модуль - как отдельный проект?
* у вас код запускался из flash? Тогда как разруливались несколько экземпляров модулей (адреса же фиксированные на этапе линковки)? Или вы копировали в ОЗУ? Или не применяли команды, которые работают с фиксированными адресами, только по смещению?
* где жила системная библиотека (общая для всех модулей)?
* что происходит с глобальными и статическими переменными? У каждого модуля фиксированный регион RAM? Или все хранится в куче?
* межмодульное взаимодействие как было организовано? Т.е. как позвать функцию из другого модуля?

[KnightIgor]

Вот бы его на github'е увидеть !

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

[bugdesigner]

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

CODE

#define APP_ADDRESS (uint32_t)0x08004000

typedef void (*pFunction)(void);
pFunction Jump_To_App;
uint32_t JumpAddr;

int main(void)
{
init_hw(); // Hardware init

upgrade_firmware();

if(check_firmware())
{
// Jump to application
JumpAddr = *(__IO uint32_t*) (APP_ADDRESS + 4);
Jump_To_App = (pFunction) JumpAddr;
// Initialize application's Stack Pointer
__set_MSP(*(__IO uint32_t*) APP_ADDRESS);
Jump_To_App();
}
else Fault();

return 0;
}

APP_ADDRESS - адрес, с которого начинается основное приложение.

upgrade_firmware() - процедура записи приложения в флеш - ищем на SD, если находим, сверяем версию (чтоб не перезписывать одно и то же), обновляем.
check_firmware() - проверяем наличие / валидность приложения. Я, например, считаю CRC, Вы можете изобрести другой метод (напимер ЭЦП).
Fault() - говорит сам за себя - приложения нет / повреждено - "моргаем красным светодиодом".

Основное приложение пишется как обычно, только адрес заггрузки указывается равный APP_ADDRESS.
В Keil это делается в опциях проекта. Project -> Options for target -> Target поле IROM1 = 0x08004000
Кроме этого нужно указать адрес таблицы векторов прерываний равный APP_ADDRESS. Делается это правкой файла system_*.c.
Ищем строку #define VECT_TAB_OFFSET 0x0 и заменяем на свой оффсет #define VECT_TAB_OFFSET 0x4000

[kolobok0]

...* как тестировали? ..Каждый модуль - как отдельный проект?...у вас код запускался из flash?
...Или не применяли команды, которые работают с фиксированными адресами, только по смещению?
* где жила системная библиотека (общая для всех модулей)?
...Или все хранится в куче?
... как позвать функцию из другого модуля?

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

зачем = повышенная отказоустойчивость. и минимум требований к фазе дистанционной апгрэйта кода.

(круглый)

[inventor]

Сделал, но чего то не получается запустить основную программу
в чем может быть проблема?

утилитой ST Link проверяю - файл записался и лежит правильно в памяти
Загрузчик у меня такой:

CODE

#define FILE_NAME "loader.bin"
#define APP_ADDRESS (uint32_t)0x08008000


do {
/* Монтируем. Если нет файла - выходим на загрузку */
if ((rc = f_mount(0, &fatfs)) == 0) {
PRINTF("INFO: mount OK\r\n");
} else {
PRINTF("ERROR: mount fs\n");
break;
}

/* Открыть на чтение */
rc = f_open(&fil, FILE_NAME, FA_READ);
if (rc == 0) {
PRINTF("INFO: Loader file %s open OK\n", FILE_NAME);
} else {
PRINTF("INFO: Loader file %s doesn't exist. Continue booting", FILE_NAME);
break;
}

/* стираем секторы 2...4*/
FLASH_Unlock();
delay_ms(50);

if(FLASH_COMPLETE == FLASH_EraseSector(FLASH_Sector_2, VoltageRange_3)) {
PRINTF("Erase sector OK\n");
led_toggle(LED3);
}

if(FLASH_COMPLETE == FLASH_EraseSector(FLASH_Sector_3, VoltageRange_3)) {
PRINTF("Erase sector OK\n");
led_toggle(LED3);
}

if(FLASH_COMPLETE == FLASH_EraseSector(FLASH_Sector_4, VoltageRange_3)) {
PRINTF("Erase sector OK\n");
led_toggle(LED3);
}


/* Читаем файл и записываем в секторы flash */
bytes = 0;
addr = APP_ADDRESS;
do {
bw = 0;
rc = f_read(&fil, buf, sizeof(buf), &bw);
if (rc == 0 && bw > 0) {
bytes += bw;
for(i = 0; i < bw; i++) {
FLASH_ProgramByte(addr, buf[i]);
addr++;
}
PRINTF("%d bytes written\n", bytes);
led_toggle(LED4);
delay_ms(50);
}
} while (bw);

rc = f_close(&fil);

// Стираем файл
/* Если файл существует - удалим его */
// rc = f_unlink(FILE_NAME);

} while (0);

/* Disable all interrupts */
RCC->CIR = 0x00000000;

/* Делаем старт по адресу */
JumpAddr = *(__IO uint32_t*) (APP_ADDRESS + 4);
Jump_To_App = (pFunction) JumpAddr;

/* Initialize application's Stack Pointer */
__set_MSP(*(__IO uint32_t*) APP_ADDRESS);
Jump_To_App();

Я вижу отладчиком, что до джампа он доходит - а дальше аут

основная прога использует такой скрипт линкера, где установлены адреса:

define symbol __ICFEDIT_intvec_start__ = 0x08008000;
define symbol __ICFEDIT_region_ROM_start__ = 0x08008000;

+ сделал коментарий в вызове из ассемблера SystenInit() - так это уже сделано в загрузчике
компилю образ проги и получаю бинарник program.bin

CODE

;Reset_Handler

; LDR R0, =SystemInit
; BLX R0
LDR R0, =__iar_program_start
BX R0

В чем может быть еще засада?

[scifi]

Я вижу отладчиком, что до джампа он доходит - а дальше аут

А поподробнее? В окне дизассемблера нашли инструкцию, которая делает не то, что нужно? Посмотрели значения соответствующих регистров?

[Kabdim]

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

А вот это самодельное или от линукс-арм прикрутили?

[inventor]

А поподробнее? В окне дизассемблера нашли инструкцию, которая делает не то, что нужно? Посмотрели значения соответствующих регистров?

делает branch BLX R8
тока в R8 почему то 0x08009f85

[scifi]

тока в R8 почему то 0x08009f85

А это хорошо или плохо? Мы же не знаем точку входа в вашу основную программу. Может быть, она там и есть.
Советую отладчиком пройти по этой инструкции и посмотреть, куда она выводит. И кейл, и яр позволяют загрузить отладочную информацию для двух программ (загрузчика и основной программы), то есть переход будет прозрачным для отладчика. Весьма вероятно, что падает основная программа, потому что вы что-то не учли.

[kolobok0]

А вот это..

самодельное.

[KRS]

Код

    /* Disable all interrupts */
       RCC->CIR = 0x00000000;
    
      /* Делаем старт по адресу */
    JumpAddr = *(__IO uint32_t*) (APP_ADDRESS + 4);
    Jump_To_App = (pFunction) JumpAddr;

    /* Initialize application's Stack Pointer */
    __set_MSP(*(__IO uint32_t*) APP_ADDRESS);
    Jump_To_App();

Так делать некорректно!
Во первых не устанавливается новый адрес таблицы векторов ( VTOR )
Во вторых указатель стека будет модифицирован и не будет соответствовать тому что лежит по APP_ADDRESS

И если хотите отлаживать приложение без бутлоадера (если это разные проекты) то надо у IAR в макросах установить запись VTOR - тогда можно без проблем отлаживать.

[aaarrr]

Во первых не устанавливается новый адрес таблицы векторов ( VTOR )

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

Во вторых указатель стека будет модифицирован и не будет соответствовать тому что лежит по APP_ADDRESS

Где?

[scifi]

Где?

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

Код

static const uint16_t jump2fw[] =
{
    0xF850, 0xDB04, /* LDR.W SP, [R0], #4   */
    0x6800,         /* LDR.W R0, [R0]       */
    0x4700,         /* BX R0                */
};
((void (*)(int))(1 + (int)jump2fw))(0x08010000);

[KRS]

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

Нет - загрузчика! Потому что старт приложения происходит по RESET вектору который лежит в таблице прерываний, соотв. VTOR обязан указывать туда...

Как обычно, агитирую за свой вариант

Ну можно и встроенным асмом обойтись...

[aaarrr]

Нет - загрузчика! Потому что старт приложения происходит по RESET вектору который лежит в таблице прерываний, соотв. VTOR обязан указывать туда...

Как минимум спорно. Приложение может и не придерживаться этих правил, т.к. не предназначено для непосредственного исполнения после аппаратного сброса.

Как обычно, агитирую за свой вариант

А я - за свой

Код

    __set_MSP(*((uint32_t *)IMAGE_START));
    (*((void (**)(void))(IMAGE_START + 4)))();

[inventor]

Сделал самозагрузчик,
забыл вызвать функцию NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x8000); в основной программе
теперь у меня такой вопрос
вот мой загрузчик грузит только то, что есть на внутренней flash
как быть с теми функциями и данными, которые должны располагаться
на RAM памяти? кто должен их располагать правильно?
надо ли так же перераспределить и память RAM, между загрузчиком и основной программой?

[scifi]

А я - за свой

Код

    __set_MSP(*((uint32_t *)IMAGE_START));
    (*((void (**)(void))(IMAGE_START + 4)))();

Скобок много - в глазах рябит

[KnightIgor]

вот мой загрузчик грузит только то, что есть на внутренней flash
как быть с теми функциями и данными, которые должны располагаться
на RAM памяти? кто должен их располагать правильно?
надо ли так же перераспределить и память RAM, между загрузчиком и основной программой?

Ничего специально делать не нужно. Если у Вас основная программа не bare bones (иными словами, написана в рамках среды разработки и с использованием стандартных библиотек среды), то перед переходом в main() втихую вызывается инициализация RAM. Она прочищает/устанавливает необходимые области/переменный RAM. Все, что пользовал загрузчик, будет бесследно "перезатерто".

Код

    __set_MSP(*((uint32_t *)IMAGE_START));
    (*((void (**)(void))(IMAGE_START + 4)))();

Вставлю свои 5 копеек: в ассемблерном стартовом файле я дописал:

Код

VTOR            EQU     (0xE000E000 + 0x0D08)                
StartMainApp    PROC   ; R0 - parameter with the APP vector table address
                EXPORT  StartMainApp               [WEAK]
                LDR     R1, =VTOR                  ; Load VTOR register address
                STR     R0, [R1]                   ; Store to VTOR to relocate the vector table
                LDR     SP, [R0]                   ; Reinit the user stack
                LDR     R0, [R0, #4]               ; Get the user entry point...
                BX      R0                         ; ... and jump to it
                ENDP

В С-шном файле вызов выглядит как:

Код

extern StartMainApp(uint32_t vector);
...
StartMainApp(0x08000000 + 0x4000); // для моего случая программы с 16К

[zltigo]

Ассемблерный код здесь идеологически более правильный.

Ассемблерный код в данном случае, как телеге пятое колесо .

[scifi]

Ассемблерный код в данном случае, как телеге пятое колесо .

Я ж не заставляю. У нас свободная страна. Каждый волен иметь своих тараканов в голове

[KnightIgor]

Я ж не заставляю. У нас свободная страна. Каждый волен иметь своих тараканов в голове

ОТ: о какой стране речь?

[scifi]

ОТ: о какой стране речь?

А, ну да. Разъехались, панимаишь, по свету. Космополиты

[zltigo]

А, ну да. Разъехались, панимаишь, по свету. Космополиты

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

[scifi]

В данном случае вызов пишется на чистейшем как слеза Си. Посему и пятое колесо не нужно.

Вы свою версию вызова не привели. Все уже предъявили, а Вы скрываете Код - в студию!

[zltigo]

Вы свою версию вызова не привели. Все уже предъявили, а Вы скрываете Код - в студию!

Абсолютно совпадает с той, котрую я ранее поддержал.

[scifi]

Абсолютно совпадает с той, котрую я ранее поддержал.

Наверное, поддержали мысленно, потому что здесь не видно. Ну да ладно.

[ViKo]

Коль все предъявили, тогда и я...:

Код

/* Адрес таблицы */
      SCB->VTOR = APPL_ADDR;
    
/* Указатель на приложение */
      pFunc_t JumpAppl = (pFunc_t)(*(__IO uint32_t *)(APPL_ADDR + 4));
      __set_MSP(*(__IO uint32_t *)APPL_ADDR);
      JumpAppl();

[scifi]

Коль все предъявили, тогда и я...:

Код

      __set_MSP(*(__IO uint32_t *)APPL_ADDR);
<-- компилятор может изменить значение указателя стека
      JumpAppl();

Выше было сказано: где гарантия, что компилятор не изменит значение указателя стека перед переходом?

[ViKo]

Выше было сказано: где гарантия, что компилятор не изменит значение указателя стека перед переходом?

Я, что, своего загрузчика не знаю?

[Сергей Борщ]

Все уже предъявили, а Вы скрываете

Не все еще.

CODE

struct application
{
    struct vectors
    {
        typedef void( *handler )( void );
        uint32_t    MSP_init;
        handler     Reset_vector;
        handler     Core_handler[14];
        handler     MCU_handler[MCU_VECTORS];
    }       Vectors;
    uint32_t Size;                          // application size, 4-byte words
};

extern application const Application;

....
            {
                // set vectors table to application vectors
                SCB->VTOR = (uintptr_t)&Application.Vectors;
                __set_MSP(Application.Vectors.MSP_init);
                Application.Vectors.Reset_vector();
            }

// в скрипте линкера:
    .application (NOLOAD):
    {
        Application = .;
    } > APPLICATION

[aaarrr]

Выше было сказано: где гарантия, что компилятор не изменит значение указателя стека перед переходом?

Повторюсь: раз приложение стартует после загрузчика, то все эти требования излишни. Стек и VTOR может поставить и самостоятельно. Реально нужен только переход.

[inventor]

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

[scifi]

если в начале кода делаю инициализацию USB - виснет
коментирую USB - запускается.

Не помню, говорили вам или нет. Переход на основную программу хорошо делать сразу после сброса. Именно для того, чтобы МК был в состоянии как после сброса. А если прыгаете туда абы как с инициализированными кусками периферии, то сами и разбирайтесь в своём зоопарке.