Пытаюсь сейчас переложить FreeRTOS на IAR 4.31 для LPC2214.
Натолкнулся на такую фишку в асм файле portasm.s79 в

vPortStartFirstTask:
portRESTORE_CONTEXT



При запуске тасков регистр SP выходит за пределы указанные в линкере. IAR начинает постоянно warning'и сыпать. Вопрос спецам, это вообще нормально? Причём готовый пример, который вместе с исходниками скачивается на LPC2129 вытворяет тоже самое в симуляторе.

Поскольку это мой первый опыт общения с РТОСами, на этом всё и за стряло. Запустить пока не получается. Программа пролетает создание и запуск тасков и начинает благополучно слать 55 через uart. Что не так делаю?


#include "system.h"
#include "uart.h"

/* Scheduler includes. */
#include "FreeRTOS.h"
#include "task.h"

// Task to be created.
void vTaskCode( void * pvParameters )
{
for( ;; )
{
// Task code goes here.
UART0WriteChar(0x77);
UART1WriteChar(0x77);
}
}

int main()
{
// PLL, MAM, Port's initialization
SystemInit ();
// UART initialization
InitUart0();
InitUart1();

// Create the task, storing the handle.
xTaskCreate( vTaskCode, "NAME", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL );
vTaskStartScheduler();
// loop forever
while(1) {
UART0WriteChar(0x55);
UART1WriteChar(0x55);
}

}

Не знаю как в последних версиях, а раньше приходилось дописывать Иначе если весь проект в ARM mode оно как раз с вашими симптомами и не работало.

где дописывать этот код?

вероятно там , где у вас в проэкте вообще определяется дефайн portINITIAL_SPSR
Вы ведь в ИАРе можете набрать это назвагде нибудь, нажать на тексте правой кнопкой мыши и выбрать "Go nj definition of portINITIAL_SPSR" ?

вообще то это валяется в файле
port.c

бывает, торможу.

нашёл строчку где слетает SP



к стати замена portINITIAL_SPSR с 3f на 1f не помогла и переход в thumb моде тоже. Пробовал разные варианты. Всегда одно и тоже.

Ну так в этой строчке показано, какие регистры восстанавливаются. Посмотрите, какие на стеке значения в этот момент. Сравните с теми, которые были записаны туда функцией pxPortInitialiseStack, заодно проверьте, правильные ли значения ей передаются. Кстати, в этой строчке SP не слетает, а восстанавливается из стека, возможно с изменением режима (зависит от SPSR и CPSR). Подозреваю, что стека вы для процесса пожалели и на него налезли другие данные. надо не заменять и переходить, а написать так, как я вам показал. Вместе с #if. Тогда в зависимости от режима компиляции будет автоматически подставляться нужное значение. Ибо в режиме ARM там должно быть 1F, а в режиме THUMB 3F, и только так а не наоборот.

SP и должен выходить за "пределы". ИАР кричит основываясь на данных из файла линкера. Он же не в курсе, что ОС сама назначает стеки для каждого процесса. И лежат они в каком-то внутреннем массиве FreeRTOS (сейчас негде посмотреть). Размер которого, кстати, задается где-то в файле настроек ОС, а не в файле линкера. Так что отключайте плугин Stack или не обращайте на его крики внимание.

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

Уважаемый xelax, удались ли вам решить проблему? Имею те же симптомы - возникает prefetch abort в portRESTORE_CONTEXT, правда контроллер LPC2368.

Нет не решил, пришлось отложить проблему в долгий ящик, в связи с переходом на новую работу и сменой lpc на atmel sam7.

Решил проблему. Дело оказалось как всегда, в стеке, как уже не раз писал Zltigo. Чуть мозг не сломал. Поскольку я собираю проект с помощью make, ошибка была неявной. Докопался когда не увидел в map файле стеков для fiq и svc. Оказывается, в командной строке линкера мой cstartup.r79 был в самом конце, уже после IAR' овской библиотеки, и не происходил override. Ядро запустилось, правда пока только в thumb.

Там одна строчка правится в исходниках:
http://electronix.ru/forum/index.php?showt...16114&st=41
Ну и, естествено, ключик компилятору..

Читал, спасибо; хочется ведь сразу сделать правильно - подправить кишочки FreeRTOS чтоб поуменьшить количество лишних телодвижений, так что это немного подождет.
Спасибо за cstartup, очень помог.

Я тоже напоролся на PAbort в последней инструкции макроса portRESTORE_CONTEXT(), выглядящей как SUBS PC, LR, #4

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

В моем случае все дело было в том, что я в startup.S после инициализации стеков для всех режимов оставлял процессор в режиме System, а надо было оставлять в Supervisor.
Из-за этого инструкция LDMFD LR, {R0-R14}^ замещала не ту копию R13 (SP) и R14 (LR), и поэтому последующая команда LDR LR, [LR, #+60] работала с испорченным содержимым LR, и разумеется, переходила по "мусорному" адресу.