Создание образа прошивки, состоящего из двух частей, с использованием набора инструментов GCC

Сейчас это работает, поэтому я отвечу на свой вопрос. Вот что было необходимо для этого, начиная с обычной сборки одного образа, превращая его в «ядро» и затем настраивая сборку для «приложения».

1. Решите, как разделить флэш-память и оперативную память на отдельные области для ядра и приложения. Определите начальный адрес и размер каждой области.

2. Создайте сценарий компоновщика для ядра. Это будет то же самое, что и стандартный сценарий компоновщика для платформы, за исключением того, что он должен использовать только области, зарезервированные для ядра. Это можно сделать, изменив ORIGIN и LENGTH записей флэш-памяти и ОЗУ в разделе MEMORY сценария компоновщика.

3. Создайте файл заголовка, объявляющий точку входа для приложения. Для этого нужен только прототип, например:

void app_init(void);.

4. Включите этот заголовок из основного кода C и получите основной вызов app_init() для запуска приложения.

5. Создайте файл символов, объявляющий адрес точки входа, который будет начальным адресом флэш-области для приложения. Я назову это app.sym. Это может быть одна строка в следующем формате:

app_init = 0x00010000;

6. Соберите ядро, используя сценарий компоновщика ядра и добавив --just-symbols=app.sym к параметрам компоновщика, чтобы получить адрес app_init. Сохраните файл ELF из сборки, которую я назову core.elf.

7. Создайте сценарий компоновщика для приложения. Это снова будет основано на стандартном сценарии компоновщика для платформы, но с изменением диапазонов флэш-памяти и оперативной памяти на те, которые зарезервированы для приложения. Кроме того, потребуется специальный раздел, чтобы гарантировать, что app_init помещается в начало области флэш-памяти приложения перед остальной частью кода в разделе .text:

SECTIONS
{
    .text :
    {
        KEEP(*(.app_init))
        *(.text*)

8. Напишите функцию app_init. Он должен быть в сборке, так как он должен выполнить некоторую работу на низком уровне, прежде чем любой код C в приложении может быть вызван. Его нужно будет пометить .section .app_init, чтобы компоновщик поместил его в нужное место в начале области флэш-памяти приложения. Функция app_init должна:

   1. Populate variables in the app's .data section with initial values from flash.
   2. Обнулить переменные в разделе .bss приложения.
   3. Вызовите точку входа C для приложения, которую я назову app_start().

9. Напишите app_start() функцию, запускающую приложение.

10. Создайте приложение, используя скрипт компоновщика приложений. Этот шаг связи должен быть передан объектным файлам, содержащим app_init, app_start и любой код, вызываемый app_start, который еще не находится в ядре. Параметр компоновщика --just-symbols=core.elf должен быть передан для связывания функций в ядре по их адресам. Кроме того, необходимо передать -nostartfiles, чтобы исключить обычный код запуска среды выполнения C.

Потребовалось время, чтобы разобраться во всем этом, но теперь все работает нормально.

Прежде всего ... если это только для обновления полей, вам не нужно полагаться на таблицу векторов прерываний в основном пространстве для приложения. Я думаю, что части ARM M0 всегда могут его перемещать. Я знаю, что это можно сделать на некоторых (всех?) Материалах STM32Fx, но я считаю, что это вещь ARM M-x, а не ST. Изучите это, прежде чем принимать решение сделать все ISR вашего приложения хуками, вызываемыми из ядра.

Если вы планируете много взаимодействовать со своим ядром (кстати, я всегда называю часть, которая выполняет самообновление «загрузчиком» на микроконтроллерах), вот альтернативное предложение:

Передает ли Ядро указатель на структуру / таблицу функций, описывающих его возможности, в точку входа Приложение?

Это позволит полностью разделить код приложения и ядра, за исключением общего заголовка (при условии, что ваш ABI не изменится), и предотвратит конфликты имен.

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

core.h:

struct core_functions
{
    int (*pcore_func1)(int a, int b);
    void (*pcore_func2)(void);
};

core.c:

int core_func1(int a, int b){ return a + b; }
void core_func2(void){ // do something here }

static const struct core_functions cfuncs= 
{
    core_func1,
    core_func2
};

void core_main()
{
   // do setup here
   void (app_entry*)(const struct core_functions *) = ENTRY_POINT;
   app_entry( &cfuncs );
}

app.c

void app_main(const struct core_functions * core)
{
   int res;
   res = core->pcore_func1(20, 30);
}

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