вызов супервизора 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.

[Arlleex]

Зачем?

При явной работе с PC адрес инструкции, записываемой в этот регистр, должен быть с установленным 0-м битом, указывающим на Thumb-режим.

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

Тут мне следует почитать специальный pdf-документ на эту тему, т.к. не до конца понимаю когда их ставить. В общем-то, действительно, тут вообще они не нужны. Я посчитал, что после смены активного указателя стека может что-то измениться в плохую сторону без барьерных инструкций, это не есть гуд. Перфекционист негодует
Кстати, тут прямо пишут

Note
When changing the stack pointer, software must use an ISB instruction immediately after the MSR instruction. This ensures that instructions after the ISB instruction execute using the new stack pointer. See ISB

Так что ISB надо вставлять. Выглядит даже логично - действительно конвейер надо сбросить, т.к. SP может наадресовать чего-нибудь не того в конвейверной обработке...

А если это загрузчик в ROM и его никак не изменить?
...
Боюсь представить если также будут думать разработчики ROM-бута в каком-то МК.

Будет очень плохо, конечно же По-хорошему, такого быть не должно...

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

А вот с этим я еще пока разбираюсь.
Есть регистр FPCCR, в нем биты ASPEN и LSPEN. А есть еще CONTROL с его FPCA. Причем все они взаимосвязаны и надо переварить, как именно. В примере от индусов (старый порт RTOS) в бит FPCA CONTROL пишется 0 и вызывается SVC. При этом предварительно биты ASPEN, LSPEN в FPCCR установлены в 1, а FPU-сопроцессор, естественно, включен.