Виснут процессы с более низким приоритетом.
При этом более старший процесс спокойно крутится и имеет у себя в цикле ожидание сообщения с таймаутом + Sleep.
Можно как-либо по переменным оси определить, где подвис младший процесс, или куда деваются ресурсы?

До этого была 3.05. Но там я наступил на грабли не прохождения сообщений на ожидании с таймаутом, потому перешел на более новую.

Обновил. Проблема ушла.

По поводу текущей проблемы. Есть какие-нибудь ограничения на использования channel
в обработчике прерывания? Обработчик оформлен по всем правилам работы с осью.

При использовании сервисов в прерываниях есть определенные особенности. Например, очевидно, что использовать TMutex::Lock() внутри обработчика прерывания является достаточно плохой идеей, т.к., во-первых, мутексы предназначены для разделения доступа к ресурсам на уровне процессов, а не на уровне прерываний, и, во-вторых, ожидать освобождения ресурса, если он был занят, внутри обработчика прерывания все равно не удастся и это приведет только к тому, что процесс, прерванный данным прерыванием, просто будет переведен состояние ожидания в неподходящей и непредсказуемой точке. Фактически процесс будет переведен в неактивное состояние, из которого его вывести можно будет только с помощью функции ForceWakeUpProcess. В любом случае ничего хорошего из этого не получится.

Аналогичная в некотором роде ситуация может получиться при использовании объектов-каналов в обработчике прерываний. Ждать данных из канала
внутри ISR не получится и последствия будут аналогичны вышеописанным, а записывать данные в канал тоже не вполне безопасно. Если, к примеру, при записи в канал в нем не окажется достаточно места, то поведение программы окажется далеко не таким, как ожидает пользователь.