Ошибка STM32F429 в __libc_init_array после перехода к Reset_Handler приложения из загрузчика. Почему?

Question

Я создаю собственный загрузчик USB HS DFU для своего проекта STM32F429, используя arm-none-eabi-g cc вместе с CLion IDE. У меня возникают проблемы при переходе к коду приложения из загрузчика.

Проект CLion состоит из цели загрузчика и цели образа прошивки, а также отдельной цели прошивки, которая исключает загрузчик и позволяет выполнять отладку. код приложения напрямую. Цель изображения использует модифицированный код запуска (объясняется позже), создает двоичное изображение и подписывает его с помощью специального инструмента. Этот инструмент также объединяет загрузчик и двоичные образы в один. Он устанавливает загрузчик в 0x00000000 (0x08000000 в fla sh), а прошивку в 0x0004000 (0x08040000 в fla sh). С помощью hex-редактора я могу подтвердить, что подпись и размещение частей выполнены правильно.

После перепрограммирования объединенного двоичного файла я перезаписываю sh цель загрузчика и отлаживаю ее. Непосредственно перед переходом к приложению таблица векторов перемещается в начало кода прошивки, адрес обработчика сброса приводится к указателю на функцию void (void) и называется:

void DFUBootloader::startApplication(const uint32_t *imageBase)
{
    // Copy vector table to ram be able to look at its contents in the debugger easily
    VectorTable vectorTable;
    memcpy(&vectorTable, imageBase, sizeof(VectorTable));

    // get image reset handler function pointer
    void (*imageResetHandler)() = reinterpret_cast<void(*)()>(vectorTable.resetHandler);

    // disable interrupts
    RCC->CIR = 0x00000000;

    // relocate vector table to start of image binary.
    SCB->VTOR = (uint32_t)imageBase;

    __set_MSP(vectorTable.stackPointerInitValue);

    imageResetHandler();
}

От отладчика могу подтвердить, что переход к точке входа прошивки выполнен правильно. Поскольку выполнение продолжается с точки входа микропрограммы, отладочной информации больше нет. Я не нашел способа «объединить» информацию отладки в одну, но, по крайней мере, я могу сопоставить дизассемблирование с измененным файлом сборки startup_stm32f429xx.s, подтверждая, что переход прошел успешно. Модифицированный файл запуска для образа прошивки пропускает вызов SystemInit, так как его работа уже была выполнена с помощью кода загрузчика.

По какой-то причине MCU, похоже, обрабатывает sh в процедуре __libc_init_array , Я подозреваю, что перемещение прошивки с 0x08000000 (когда она была собрана) на 0x08040000 в fla sh может быть как-то связано с этим, или, возможно, переход из кода загрузчика оставляет регистры в «грязном» состоянии. Я не могу понять, что происходит от одной разборки, но она заканчивается от blx до 0x00000000. Не уверен, что это намеренно или нет.

В надежде убрать всю работу __libc_init_array, я попытался сделать бинарный файл прошивки максимально простым, используя только скрипт компоновщика, Файл запуска и главный. c, содержащий только бесконечное время -l oop, но увы. Кто-нибудь знает как это решить?