Приветствую всех.

В проекте регулярно застывает задача при входе в sleep. Т.е. она бежит некоторое время, а потом перестает выходить из слипа одного из потоков.
При этом Timeout потока висит в нуле. Если его в отладчике снова выставить на какое-либо число, то поток отмерзает и снова работает некоторое время.
Стека там достаточно. Время на выполнение потока точно есть (все сидит в IDLE).

CPU stm32h7. За основу взят порт для stm32F3 для IAR + порт для stm32f4 FPU для GCC

Грешу на кэши, но оно работало вполне успешно на stm32F7, где это тоже присутствует.

Есть подозрение, что встал на те же грабли, но не могу их разглядеть. Может кто сможет поделиться идеей, куда покопать.

А у вас нигде случайно не получается вызов sleep(0)?

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

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

Не очень понятно, что такое "sleep снаружи". Не могли бы показать фрагмент этого кода?

sleep - это самая простая штука из всего, что там есть. В обработчике прерывания таймера просто проверяется значение переменной- таймаута процесса, если она не ноль, то декрементируется. Как только доехала до нуля, то данный процесс переводится в готовые к выполнению - в переменной ядра ReadyProcessMap устанавливается бит, соответствующий этому процессу.

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

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

Код такой

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

Да, ничего криминального нет, просто ещё одно безусловное ожидание.

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

Приоритеты прерываний? Вложенные прерывания для кортекса? Кеши в процессоре(сброс DATA не помогал)? Где еще можно поискать затык?
Как такое в принципе может возникать?

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

Если вы используете openocd, то у нас есть ветка его исходников с поддержкой scmRTOS. Он позволяет смотреть состояние и стек вызовов всех потоков. Ну очень помогает при отладке. Подробности тут.

Приоритеты проверьте, конечно.
Посмотрите, как у H7 реализован доступ к регистру SHP3. У M0 он разрешён только по словам, а у M3/4 - разрешён побайтный доступ. Если у H7 тоже доступ только по словам, то будет неправильная инициализация приоритетов прерываний. А это может привести к глюкам.

ЗЫ. Вот нужный дефайн в порте.

Антон, позанудствую чуть-чуть.

- STM32H7 - это "особо быстрый" STM на Cortex-M7
- регистр называется SHPR3
- доступ к SCB->SHPRx, везде, кроме M0 / M0+, побайтовый.

Но граблю arm знатную подложил...

Я до M7 ещё не добрался (хотя платка лежит, ждёт своего часа), поэтому отвечал просто из общих соображений.

Жалко, что автор темы пропал, и мы не знаем, решил он свою проблему или нет.



Да, помню, пришлось повозиться, вылавливая её