[BAT 0]

TStackItem* OS::TKernel::ContextSwitchHook(TStackItem* sp)
{
TCritSect cs; <--- здесь

   ProcessTable[CurProcPriority]->StackPointer = sp;
   sp = ProcessTable[schedProcPriority]->StackPointer;

#if scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE == 1
   ContextSwitchUserHook();
#endif 

   CurProcPriority = SchedProcPriority;
   return sp;
}

 

Туда я добавил? Если да, то не помогло :(. Все это чаще всего проявляется, когда активно начинает работать высокоприоритетный процес + идет активно связь по компорту, а она реализована в силу особенностей на прерываниях с использованием канала оси. OS::TISRW ISR на обработчиках стоит.

[dxp 32]

Туда я добавил? Если да, то не помогло :(. Все это чаще всего проявляется, когда активно начинает работать высокоприоритетный процес + идет активно связь по компорту, а она реализована в силу особенностей на прерываниях с использованием канала оси. OS::TISRW ISR на обработчиках стоит.

Да, добавили правильно. Если у вашего порта приоритетный контроллер прерываний и прерывание переключения контекстов может быть прервано (вытеснено) другим прерыванием, то эту критическую секцию надо там оставить (иначе чревато проблемами). В противном случае можно убрать.

 

Причину найти с ходу тяжело. Если есть возможность, то для начала добиться повторяемости (определить, при каких условиях это происходит). Тогда уже можно экспериментировать с целью локализовать проблему.

 

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

 

По размерам стеков как определили, что их объём достаточен?

 

По самой оси кроме вышеописанного косяка с приоритетными контроллерами прерываний, вопросов, вроде, не замечено.

[BAT 0]

Остальные данные в объектах-процессах не портятся. Насколько я смог увидеть.

Стек проверяю простой инициализацией его константой и потом просто в отладчике отслеживаю сколько не модифицировалось.

Пока проект в отладке стараюсь выделять с сильным запасом(часто более 2х кратного).

Кстати, в новом релизе не планируется добавить дебагрежима на такие случаи, чтоб были переменные с данными по использованию стеков?

 

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

[AHTOXA 14]

Да, добавили правильно. Если у вашего порта приоритетный контроллер прерываний и прерывание переключения контекстов может быть прервано (вытеснено) другим прерыванием, то эту критическую секцию надо там оставить (иначе чревато проблемами). В противном случае можно убрать.

В порте(ах) для Cortex-M3 прерывания при вызове OS::TKernel::ContextSwitchHook() и так запрещены:

OS_Target_asm.S:

PendSVC_ISR:
    CPSID   I                 // Prevent interruption during context switch
...
    LDR     R1, =os_context_switch_hook    // os_context_switch_hook();
    BLX     R1

так что эта критическая секция не нужна.

[dxp 32]

В порте(ах) для Cortex-M3 прерывания при вызове OS::TKernel::ContextSwitchHook() и так запрещены:

OS_Target_asm.S:

PendSVC_ISR:
    CPSID   I                 // Prevent interruption during context switch
...
    LDR     R1, =os_context_switch_hook    // os_context_switch_hook();
    BLX     R1

так что эта критическая секция не нужна.

Ты про свой порт или это у IAR'ного подсмотрел?

 

Кстати, в новом релизе не планируется добавить дебагрежима на такие случаи, чтоб были переменные с данными по использованию стеков?

Да, будет специальный режим отладки (кстати, это уже есть, лежит в репозитории в ветке, которая относится к подготовке релиза, pre-v400), и интерфейс (специальная функция) для получения информации о запасе по стеку. Также, будет возможность засекать адрес сервиса, который ожидает процесс - бывает, что процесс висит, чего-то ждёт, тут полезно бывает узнать, чего он ждёт. Ещё будет профилировка работы процессов (два вида, в виде расширений). Всё это будет подробно описано в документации.

 

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

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

[AHTOXA 14]

Ты про свой порт или это у IAR'ного подсмотрел?

Это у обоих портов так, изначально.

[dxp 32]

Это у обоих портов так, изначально.

Гуд, значит для этих портов ничего не надо делать.

[kostyan1 0]

Аналогично BATу, словил зависание процесса. Вставал высокоприоритетный процесс опроса клавиатуры - когда начиналась в низкоприоритетном процессе активная передача инфы по USART с использованием прерываний (причем сама передача в фоне в задаче, прием коротких команд на чтение данных только в прерывании)! На cortex m3 от атмела sam3u4. Можно сказать "по совету" dxp поигрался с приоритетом прерывания usart-а, выставил ему минимальный приоритет 15-й. И, тьфу тьфу, о чудо - сейчас всё робит! Но в будущих проектах конечно боязно теперь юзать scmRTOS. Как бы и не особо собирался - освоил более менее TNKernel (больше нравится), но факт остается фактом - не у одного меня встают процессы на кортексах на scmRTOS. Похорошему бы перевести проект на TNKernel с изначальными приоритетами прерываний и посмотреть как оно будет. Но проект огромный - времени нет (да и думаю желания у начальства). Вот так вот, может кому поможет - поиграться с приоритетами прерываний.

[Артём__ 0]

Аналогично BATу, словил зависание процесса. Вставал высокоприоритетный процесс опроса клавиатуры - когда начиналась в низкоприоритетном процессе активная передача инфы по USART с использованием прерываний (причем сама передача в фоне в задаче, прием коротких команд на чтение данных только в прерывании)! На cortex m3 от атмела sam3u4. Можно сказать "по совету" dxp поигрался с приоритетом прерывания usart-а, выставил ему минимальный приоритет 15-й. И, тьфу тьфу, о чудо - сейчас всё робит! Но в будущих проектах конечно боязно теперь юзать scmRTOS. Как бы и не особо собирался - освоил более менее TNKernel (больше нравится), но факт остается фактом - не у одного меня встают процессы на кортексах на scmRTOS. Похорошему бы перевести проект на TNKernel с изначальными приоритетами прерываний и посмотреть как оно будет. Но проект огромный - времени нет (да и думаю желания у начальства). Вот так вот, может кому поможет - поиграться с приоритетами прерываний.

 

О какой версии идёт речь? 3 или 4?

[kostyan1 0]

3.11