BAT

Проблема так и не ушла. В процессе отладки стало ясно, что двойное ожидание здесь ни при чем. Вылезает во всех местах, где есть ожидание со временем (sleep, event(s)). Там, где sleep или ожидание с таймаутом заменил на простой блокирующий event (раздаю события из таймерного хука), проблем не влезает. Приоритеты прерываний? Вложенные прерывания для кортекса? Кеши в процессоре(сброс DATA не помогал)? Где еще можно поискать затык? Как такое в принципе может возникать?

Сомневаюсь, что это проблема самой оси. Скорее в привязке к конкретному железу. Либо какие-то некорректные действия в других потоках. Код такой for(;;) { coder.process(); OS::sleep(10); } внутри coder.process() есть такая конструкция с OS::TEventFlag Ready; if(Ready.wait(10)) { ... } Одно ожидание лишнее, наскоро лепил из разных кусков, чтоб быстрее запустить. Но, в теории, не должно было тормозиться. Сейчас sleep убрал, не застревает.

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

Приветствую всех. В проекте регулярно застывает задача при входе в sleep. Т.е. она бежит некоторое время, а потом перестает выходить из слипа одного из потоков. При этом Timeout потока висит в нуле. Если его в отладчике снова выставить на какое-либо число, то поток отмерзает и снова работает некоторое время. Стека там достаточно. Время на выполнение потока точно есть (все сидит в IDLE). CPU stm32h7. За основу взят порт для stm32F3 для IAR + порт для stm32f4 FPU для GCC Грешу на кэши, но оно работало вполне успешно на stm32F7, где это тоже присутствует. Есть подозрение, что встал на те же грабли, но не могу их разглядеть. Может кто сможет поделиться идеей, куда покопать.

Сам отвечу. Работает все нормально. Косяк был от невовремя вызванной функции инициализации HAL . Временами работал, временами нет.

Всем доброго дня! У кого-нибудь есть удачный опыт использования оси на STM32F7xx? Пробую работать на версии 5.1 под IAR 7.60 опираясь на порты под М4ку. FPU отключаю. Кеш тоже для чистоты экспиремента отключен (со включеным тоже тестировал). Все работает нормально, пока процессов не больше 4х (как в примерах). Стоит увеличить на один - улет в HardFault_Handler. Есть ощущение, что где-то упустил что-то простое. Подскажите, если кто знает, где тут косяк может быть.

Приветствую всех. Пользуюсь этой платой. Возникла необходимость задействовать первый USB (PA11, PA12) Бьюсь уже несколько дней. Нет рабочего результата. Для надежности даже экран снял. Пробовал встроенный бут запустить на этот порт. Тоже не все хорошо. Плата увиделась только после перезамыкания JP3 при подключеном USB. На втором USB (PB14, PB15) проблем с работой нет. Те же исходники для обычной 4ки работают нормально. Errata молчит. Кто-нибудь сталкивался с этим? Решаемо ?

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

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 на обработчиках стоит.

ну да :) конечно для каждого процесса свой просто как-то по старой очень привычке называю их одним иногда Попробую добавить TCritSect cs. Попозже напишу результат.

Столкнулся с похожей проблемой. Есть проект, где в паре процессов используется в основном цикле Sleep. Что-то типа for(;;) { Sleep(10); . . . } Время от времени (достаточно редко) процессы застревают именно в Sleep. Timeout процесса при этом равен нулю. Процесс к выполнению в карте процессов не готов. Порт под STM Cortex-M3. IAR 6.10. Стек не переполняется с запасом. Какие, хотя бы приблизительно, могут быть косяки с моей стороны приводящие к такому результату? Не могу понять, где копать. Некорректное использование переменных с доступом из разных процессов может приводить к такому? Правда одновременная модификация нигде не используется.

Поменял местами. Как и ожидалось, проблема ушла. Спасибо. :)

Согласен, не так выразился. Не прерывает, а просто просыпается более высокоприоритетный. По поводу поменять местами. В принципе проблему решит. Правда сначала вывалится с ошибкой таймаута (практически он таки имел место), а при повторном входе сразу выйдет с уже нужным сообщением. Наверное так логичнее, чем сделал. Просто в лоб поставил чистку ConsumersProcessMap. if(pool.get_count()) { p->Timeout = 0; item = pool.pop(); CheckWaiters(ProducersProcessMap); ClrPrioTag(ConsumersProcessMap, PrioTag); // remove current process from the wait map return true; } При таком варианте вываливания с таймаутом не будет, что наверное не совсем корректно.

Ну вроде похоже отловил причину. Не знаю как назвать, багом или особенностью Scm. Что получилось. Процесс с более высоким приоритетом прерывает ожидающий сообщений из канала. ConsumersProcessMap соответственно указывает, что процесс в ожидании. Далее Высокоприоритетный начинает отрабатываться достаточно долго, чтоб в ожидающем процессе произошел таймаут ожидания сообщения из канала. Ожидающий процесс встал в готовность. Теперь высокоприоритетный доходит до конца выполнения и кладет элемент в очередь сообщений, естественно не обнуляя ConsumersProcessMap (ожидающий процесс уже готов!). Далее управление передается ожидавшему процессу и тут идет проверка на наличие элемента в очереди (а он уже есть!), соответственно ConsumersProcessMap тоже в этом месте не нулится, как при вылетании по таймауту. Итого: Теперь если процесс попытается встать на ожидание какого-то другого события и в очередь сообщений придет элемент получится пролет ожидание этого события. Вот думаю, что делать. Добавить чистку ConsumersProcessMap во время POP из канала? Но получится идеологически неверно влезать в сорцы оси. Но и в своем коде менять принцип не хочется.

Нащупал точку проблемы. Похоже я неправильно использую средства оси. Или это такая особенность. Есть некая очередь сообщений. По некоему сообщению проваливаемся в обработчик, и там в одном месте есть ожидание флага. Теперь пока мы ждем флага в очередь сообщений приходит новое. И система воспринимает это, как событие, по которому пора разбудить процесс. Более внимательно посмотрел в отладчике. После вынимания из очереди очередного элемента не чистится флаг в ConsumersProcessMap. Соответственно приход нового элемента будит процесс и Wait у Event проваливается сразу. Это баг или так и должно быть и сам подход использования неверен? if (SystemMsg.pop(sysmsg,100)) { switch(sysmsg.msg) { case KEY_PRESSED: { // перешли в новое // здесь ожидаем некоего флага Rquest_done.Wait(5000); }break; ... }//switch } else { // делать что-то } Вот еще один момент. Такое проявляется при приходе сообщения (push элемента chanal) из более высокоприоритетного потока. В момент проверки ожидающих потоков, стоит бит, что он ready (вполне возможно просто прерван верхним потоком) и при этом ConsumersProcessMap указывает, что этот самый готовый поток ждет сообщения. Чудеса. Из менее приоритетного ConsumersProcessMap обнуляется, там таких странных вещей не наблюдается. Пробовал поймать, где застревает флаг ожидания. Не получается.