BAT 0 30 марта, 2011 Опубликовано 30 марта, 2011 · Жалоба 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 36 30 марта, 2011 Опубликовано 30 марта, 2011 · Жалоба Туда я добавил? Если да, то не помогло :(. Все это чаще всего проявляется, когда активно начинает работать высокоприоритетный процес + идет активно связь по компорту, а она реализована в силу особенностей на прерываниях с использованием канала оси. OS::TISRW ISR на обработчиках стоит. Да, добавили правильно. Если у вашего порта приоритетный контроллер прерываний и прерывание переключения контекстов может быть прервано (вытеснено) другим прерыванием, то эту критическую секцию надо там оставить (иначе чревато проблемами). В противном случае можно убрать. Причину найти с ходу тяжело. Если есть возможность, то для начала добиться повторяемости (определить, при каких условиях это происходит). Тогда уже можно экспериментировать с целью локализовать проблему. По симптомам вообще похоже на переполнение стека, когда данные стека налезают на чужую память. Ну, и вообще, такое поведение характерно для ошибок работы с памятью, когда из-за неправильной адресации портится чужая память. Посмотрите - остальные потроха объекта-процесса не портятся? Только Timeout? По размерам стеков как определили, что их объём достаточен? По самой оси кроме вышеописанного косяка с приоритетными контроллерами прерываний, вопросов, вроде, не замечено. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
BAT 0 30 марта, 2011 Опубликовано 30 марта, 2011 · Жалоба Остальные данные в объектах-процессах не портятся. Насколько я смог увидеть. Стек проверяю простой инициализацией его константой и потом просто в отладчике отслеживаю сколько не модифицировалось. Пока проект в отладке стараюсь выделять с сильным запасом(часто более 2х кратного). Кстати, в новом релизе не планируется добавить дебагрежима на такие случаи, чтоб были переменные с данными по использованию стеков? Самое неприятное, что ошибка вылезает нечасто. И пока не могу добиться стабильности в этом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 30 марта, 2011 Опубликовано 30 марта, 2011 · Жалоба Да, добавили правильно. Если у вашего порта приоритетный контроллер прерываний и прерывание переключения контекстов может быть прервано (вытеснено) другим прерыванием, то эту критическую секцию надо там оставить (иначе чревато проблемами). В противном случае можно убрать. В порте(ах) для 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 36 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба В порте(ах) для 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 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба Ты про свой порт или это у IAR'ного подсмотрел? Это у обоих портов так, изначально. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 36 31 марта, 2011 Опубликовано 31 марта, 2011 · Жалоба Это у обоих портов так, изначально. Гуд, значит для этих портов ничего не надо делать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kostyan1 0 5 июня, 2012 Опубликовано 5 июня, 2012 · Жалоба Аналогично BATу, словил зависание процесса. Вставал высокоприоритетный процесс опроса клавиатуры - когда начиналась в низкоприоритетном процессе активная передача инфы по USART с использованием прерываний (причем сама передача в фоне в задаче, прием коротких команд на чтение данных только в прерывании)! На cortex m3 от атмела sam3u4. Можно сказать "по совету" dxp поигрался с приоритетом прерывания usart-а, выставил ему минимальный приоритет 15-й. И, тьфу тьфу, о чудо - сейчас всё робит! Но в будущих проектах конечно боязно теперь юзать scmRTOS. Как бы и не особо собирался - освоил более менее TNKernel (больше нравится), но факт остается фактом - не у одного меня встают процессы на кортексах на scmRTOS. Похорошему бы перевести проект на TNKernel с изначальными приоритетами прерываний и посмотреть как оно будет. Но проект огромный - времени нет (да и думаю желания у начальства). Вот так вот, может кому поможет - поиграться с приоритетами прерываний. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Артём__ 0 7 июня, 2012 Опубликовано 7 июня, 2012 · Жалоба Аналогично BATу, словил зависание процесса. Вставал высокоприоритетный процесс опроса клавиатуры - когда начиналась в низкоприоритетном процессе активная передача инфы по USART с использованием прерываний (причем сама передача в фоне в задаче, прием коротких команд на чтение данных только в прерывании)! На cortex m3 от атмела sam3u4. Можно сказать "по совету" dxp поигрался с приоритетом прерывания usart-а, выставил ему минимальный приоритет 15-й. И, тьфу тьфу, о чудо - сейчас всё робит! Но в будущих проектах конечно боязно теперь юзать scmRTOS. Как бы и не особо собирался - освоил более менее TNKernel (больше нравится), но факт остается фактом - не у одного меня встают процессы на кортексах на scmRTOS. Похорошему бы перевести проект на TNKernel с изначальными приоритетами прерываний и посмотреть как оно будет. Но проект огромный - времени нет (да и думаю желания у начальства). Вот так вот, может кому поможет - поиграться с приоритетами прерываний. О какой версии идёт речь? 3 или 4? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kostyan1 0 8 июня, 2012 Опубликовано 8 июня, 2012 · Жалоба 3.11 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться