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

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

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

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

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

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

Остальные данные в объектах-процессах не портятся. Насколько я смог увидеть.
Стек проверяю простой инициализацией его константой и потом просто в отладчике отслеживаю сколько не модифицировалось.
Пока проект в отладке стараюсь выделять с сильным запасом(часто более 2х кратного).
Кстати, в новом релизе не планируется добавить дебагрежима на такие случаи, чтоб были переменные с данными по использованию стеков?

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

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

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

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


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


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

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

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

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

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

3.11