| |
|
  |
 Переключение контекста в FreeRTOS, возникает data abort |
|
|
|
|
 Dec 7 2007, 11:54
|
Местный
Группа: Свой
Сообщений: 370
Регистрация: 7-11-06
Пользователь №: 22 035
|
sam7x gcc Собственно проблема в следующем. При сохраннении контекста в прерывании от PIT таймера (на нём переключение между задачами висит в preemptive mode) происходит data abort.  Как такое может быть????? При чём смотрю стек вызовов в arm-elf-gdb(Eclipse) вижу следующую картину
data abort
vPreemptiveTick
vPreemptiveTick
То есть либо vPreemptiveTick два раза вызывалось, либо глюк gdb. Вообще очень непонятный случай. Как такое может быть? И как с этим бороться? Код void vPreemptiveTick( void ) __attribute__((naked));
void vPreemptiveTick( void )
{
/* Save the context of the current task. */
portSAVE_CONTEXT(); <----- происходит data abort
/* Increment the tick count - this may wake a task. */
vTaskIncrementTick();
/* Find the highest priority task that is ready to run. */
vTaskSwitchContext();
/* wdt firing verification */
halWdtHandler();
/* End the interrupt in the AIC. */
AT91C_BASE_AIC->AIC_EOICR = AT91C_BASE_PITC->PITC_PIVR;;
portRESTORE_CONTEXT();
}
|
|
|
|
|
|
|
|
Dec 7 2007, 15:38
|
Местный
Группа: Свой
Сообщений: 370
Регистрация: 7-11-06
Пользователь №: 22 035
|
Цитата(klen @ Dec 7 2007, 16:47)  а crt.s ппокажи. мож забыл перевести из режима SYSTEM в SUPERVISOR перед вызовом main. шедуллер нада запускать из под супервизора. Да нет всё перевожу как надо... Проект даже какое-то время работает. А потом такая фигня вылазит. К стати когда увеличил стек задачи до 4к, стала вылазить реже. Сдаётся мне, что где-то кто-то по стеку проходится и гадит там. Другого вывода пока не вижу. Не FreeRTOS же глючит  К стати вопрос такой, а в USER моде что-нибудь крутится. Нужно ли для этого режима стек выделять?
Сообщение отредактировал xelax - Dec 7 2007, 15:41
|
|
|
|
|
|
|
|
Dec 8 2007, 06:38
|
Местный
Группа: Свой
Сообщений: 370
Регистрация: 7-11-06
Пользователь №: 22 035
|
Цитата(klen @ Dec 7 2007, 22:29) у меня он начинается с конца всех остальных стеков вниз, соответственно он "вниз" до начала блоков содержащих данные. Тоесь все что осталось от выделение всего другого. То же самое и у меня... Еще вопросец, а если закончится стек выделяемый под задачу, как себя FreeRTOS при переключения контекста поведет?
|
|
|
|
|
|
|
|
Dec 8 2007, 10:22
|
бессмертным стать можно тремя способами
Группа: Свой
Сообщений: 1 405
Регистрация: 9-05-06
Из: Москва
Пользователь №: 16 912
|
Цитата(xelax @ Dec 8 2007, 09:38) То же самое и у меня...
Еще вопросец, а если закончится стек выделяемый под задачу, как себя FreeRTOS при переключения контекста поведет? я полагаю два варианта: 1. стек задачки самый нижний, тогда похерятся данные и когда ктонить с ними будет работать то может произойти аботр(например если там указатели были) 2. стек задачки самый не самы нижний, тогда захерится вершинка стека другой задачки, что тоже приведет к траблам - ну например она просто не сможет востановить свой контекст и будет опятже глюк я щас для тестирования состояния стеков хочу попробывать такуй финт. прописать 0xffffffff с (конца памяти - 32байта) до конца стека крайней задачки, таким образом знаем адреса границ стеков и мониторим в пиковое использование стеков во всех задачках. Наверно есть чтото более умное но я тока щас подумал об этом
|
|
|
|
|
|
|
|
Dec 10 2007, 06:54
|
Местный
Группа: Свой
Сообщений: 370
Регистрация: 7-11-06
Пользователь №: 22 035
|
Цитата(klen @ Dec 8 2007, 13:22) я полагаю два варианта:
1. стек задачки самый нижний, тогда похерятся данные и когда ктонить с ними будет работать то может произойти аботр(например если там указатели были)
2. стек задачки самый не самы нижний, тогда захерится вершинка стека другой задачки, что тоже приведет к траблам - ну например она просто не сможет востановить свой контекст и будет опятже глюк
я щас для тестирования состояния стеков хочу попробывать такуй финт. прописать 0xffffffff с (конца памяти - 32байта) до конца стека крайней задачки, таким образом знаем адреса границ стеков и мониторим в пиковое использование стеков во всех задачках. Наверно есть чтото более умное но я тока щас подумал об этом Стек для задачи выделяется в куче (heap). На общий стек программы не должен повлиять. По крайней мере я попробовал по шагам походить и получил при создании задачи попадание в функцию выделения памяти из кучи. Как эксперимент прошёл, результаты какие?
Сообщение отредактировал xelax - Dec 10 2007, 06:54
|
|
|
|
|
|
|
|
Dec 10 2007, 07:24
|
Местный
Группа: Свой
Сообщений: 370
Регистрация: 7-11-06
Пользователь №: 22 035
|
Цитата(Alechek @ Dec 10 2007, 10:14) Бр... так вроде сама FreeRTOS может мониторить стеки.
хинт: vTaskList() Очень интересно,
Lists all the current tasks, along with their current state and stack usage high water mark.
А подробней, что содержится в отладочной информации есть информация. Что-то в описании нет ничего конкретного.
|
|
|
|
|
|
|
|
Dec 11 2007, 15:35
|
Местный
Группа: Свой
Сообщений: 370
Регистрация: 7-11-06
Пользователь №: 22 035
|
Цитата(Сергей Борщ @ Dec 11 2007, 16:10) Перепешите процедуры вход а выхода. После выхода состояние разрешения прерываний должно быть таким же, как и перед входом. Иначе как организовывать вложенные критические секции? Я не силён в ассемблере, как в локальную переменную адрес, которой заранее не известен сохранить значение CPSR регистра.??? Код uint32_t temp;
asm volatile (
"STMDB SP!, {R0} \n\t" /* Push R0. */
"MRS R0, CPSR \n\t" /* Get CPSR. */
"ORR R0, R0, #0xC0 \n\t" /* Disable IRQ, FIQ. */
"MSR CPSR, R0 \ n\t" /* Write back modified value. */
"LDMIA SP!, {R0}" ); /* Pop R0. */
/* Enable interrupts as per portEXIT_CRITICAL(). */
asm volatile (
"STMDB SP!, {R0} \n\t" /* Push R0. */
"MRS R0, CPSR \n\t" /* Get CPSR. */
"BIC R0, R0, #0xC0 \n\t" /* Enable IRQ, FIQ. */
"MSR CPSR, R0 \n\t" /* Write back modified value. */
"LDMIA SP!, {R0}" ); /* Pop R0.
|
|
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|
