вызов супервизора SVCall в STM32 Опции

[FFFF]

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

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

как правильно должно это все работать по задумкам разработчиков?

Сообщение отредактировал FFFF - Aug 31 2018, 10:38

[Arlleex]

В общем, выделил часок на свои изыскания и, определенно, пришел к некоторому успеху.
Повторюсь, что я хотел сделать.
Имеется FreeRTOS v10.0.0, компилятор ARMCCv5 Keil.
В системе есть 2 задачи:

CODE

xTaskHandle Task1Handle;
xTaskHandle Task2Handle;

void Task1(void *Parameters)
{
while(1)
{
HW_LED_TOGGLE(GPIO_LED1);

vTaskDelay(1000);
}
}

void Task2(void *Parameters)
{
while(1)
{
HW_LED_TOGGLE(GPIO_LED2);

vTaskDelay(500);
}
}

int main(void)
{
HW_MCUInit();

xTaskCreate(&Task1, "Task1", 128, NULL, 1, &Task1Handle);
xTaskCreate(&Task2, "Task2", 128, NULL, 1, &Task2Handle);

vTaskStartScheduler();

return 0;
}

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

1. Удалил обработчик SVC.
2. Скорректировал функцию запуска первой задачи следующим образом:

Код

__asm void prvStartFirstTask(void)
{
    PRESERVE8
    
    // установка MSP
    ldr r0, =0xE000ED08
    ldr r0, [r0]
    ldr r0, [r0]
    msr msp, r0
    
    dsb
    
    // получение указателя на стековый фрейм задачи
    ldr r3, =pxCurrentTCB
    ldr r1, [r3]
    ldr r0, [r1]
    
    // последовательная загрузка контекста
    ldmia r0!, {r4-r11, r14} // загрузка R4-R11, LR (LR здесь уже, по сути, является аттавизмом)
    msr psp, r0              // установка PSP
    
    dsb
    
    // перевод CPU на использование стека PSP
    mov r0, #2
    msr control, r0
    
    dsb
    
    // извлечение XPSR из стекового фрейма
    mrs r1, psp
    add r1, r1, #28
    ldr r0, [r1]
    msr xpsr, r0
    
    // извлечение оставшихся регистров
    pop {r0-r3, r12, r14}
    
    // корректировка бита 0 регистра PC
    push {r0, r1}
    
    mrs r0, psp
    add r0, r0, #8
    ldr r1, [r0]
    orr r1, r1, #1
    str r1, [r0]
    
    pop {r0, r1}
    
    // переход на активную задачу
    pop {r15}
}

Примечания:

1. Как видно в конце ассемблерного кода, я подменяю в памяти адрес задачи на тот же, только с установленным 0-м битом. И он останется там, в то время, как адреса других задач будут иметь 0 в этом бите. Можно и тут заморочиться и исправить, но я пока не стал. Большой проблемы это не доставит, т.к. этот адрес является адресом начала задачи, а при переключении контекста там будет уже другой адрес (чуть ниже точки входа в задачу).
   
2. Поставил DSB в местах, где меняется SP, а также после записи в CONTROL (как рекомендует ARM). Хотелось бы выслушать мнение насчет расстановки DSB, желательно аргументированно ISB убрал полностью, ибо не вижу в них смысла здесь.
   
3. Подразумевается, что в системе нет загрузчика, или загрузчик, после выполнения своего кода и перехода на пользовательское приложение, привел все регистры в состояние после сброса, а также режим работы CPU и активный SP.

В общем-то проверил - работает, и я рад, что оно получилось

[jcxz]

[*]Как видно в конце ассемблерного кода, я подменяю в памяти адрес задачи на тот же, только с установленным 0-м битом.

Зачем?

[*]Поставил DSB в местах, где меняется SP, а также после записи в CONTROL (как рекомендует ARM). Хотелось бы выслушать мнение насчет расстановки DSB, желательно аргументированно ISB убрал полностью, ибо не вижу в них смысла здесь.

Зачем DSB после записи в SP? А в программе в куче мест где делается PUSH ... или ADD/SUB SP, ... тоже будете DSB расставлять?
DSB задерживает выполнение последующих после неё команд пока не завершатся все текущие/отложенные доступы к памяти как я понимаю.
Зачем её ставить после пересылки в SP если эта загрузка никак к памяти не обращается?
Хотя она конечно не помешает, но сэкономив на пуговицах Вы добавили кучу лишних команд, перфекционист должен негодовать

После модификации CONTROL DSB тоже лишняя. Я вижу - Вы не запрещаете прерывания на время всех манипуляций. Подумайте что будет если между модификацией CONTROL и DSB произойдёт прерывание? Это показывает - что DSB неэффективна тут.
Да и вообще - такие манипуляции с CONTROL я бы не рисковал делать при разрешённых прерываниях. В uCOS-II например не только никак не обращаются к CONTROL, но и все манипуляции с переключениями стеков и пр. делают при запрещённых прерываниях.

[*]Подразумевается, что в системе нет загрузчика, или загрузчик, после выполнения своего кода и перехода на пользовательское приложение, привел все регистры в состояние после сброса, а также режим работы CPU и активный SP.

А если это загрузчик в ROM и его никак не изменить?

PS: Когда на на ARM9 в CCS сталкивался с тем, что штатный стартап-код (цепляемый штатным CCS) переводил CPU в непривилегированный режим. И все операции с привилегированными ресурсами вызывали fault-ы. Писателями этого стартапа подразумевалось видимо, что работать с такими ресурсами следует только из обработчика SVC. Пришлось найти исходники стартапа и исправить их мнение - только так.
Боюсь представить если также будут думать разработчики ROM-бута в каком-то МК.

PPS: Кстати - не вижу в Вашем коде никаких манипуляций с FPU, хотя вроде писали что он для Cortex-M4.