Не работает шедулер OS на MSP430F5437a Опции

[SMRM]

В проекте на MSP430F5437a пытаюсь применить uCOS-III.
По старту OS в OSStart(&os_err) - заполняются TCB - вроде все правильно.
Затем начинается вызов самих тасков в порядке приоритета.
Сначала вызывается первый task - все нормально.
Затем первый task в pend, переходим на второй. И здесь проблема в schedulere.
Вместо перехода на следующий похоже возвращаемся на старую точку.
Вот код:
OSCtxSw
POPX.W R12 ; Pop lower 16 bits of PC.

POPX.W R13 ; Pop upper 4 bits of PC.

PUSHX.W R12 ; Save lower 16 bits of PC.

RLAM.A #4, R13 ; Save SR + upper 4 bits of PC.
RLAM.A #4, R13
RLAM.A #4, R13
MOVX.W SR, R12
ADDX.A R13, R12
PUSHX.W R12

PUSHM.A #12, R15 ; Save R4-R15.

MOVX.A &OSTCBCurPtr, R13 ; OSTCBCurPtr->StkPtr = SP
MOVX.A SP, 0(R13)

CALLA #OSTaskSwHook

MOVX.B &OSPrioHighRdy, R13 ; OSPrioCur = OSPrioHighRdy
MOVX.B R13, &OSPrioCur

MOVX.A &OSTCBHighRdyPtr, R13 ; OSTCBCurPtr = OSTCBHighRdyPtr
MOVX.A R13, &OSTCBCurPtr

MOVX.A @R13, SP ; SP = OSTCBHighRdyPtr->StkPtr

POPM.A #12, R15 ; Restore R4-R15.

RETI

После
POPM.A #12, R15
все регистры заполняются верно(смотрел в debug), в том числе и SP.
Если поставить точку останова на RETI и затем сделать один шаг в Debug, то
переходит как и требуется на следующий task, записанный в контексте.
Если же после RETI продолжить в автомате, то переключается не на task,
а похоже в точку вызова OSCtxSw.

[k155la3]

Тики тикают ? Проверьте не на отладчике, а аппаратно, методом ногодрыга.
Неполиткорректный вопрос. Почему uCOS, а не scmRTOS или FreeRTOS ?

[SMRM]

Тики тикают ? Проверьте не на отладчике, а аппаратно, методом ногодрыга.
Неполиткорректный вопрос. Почему uCOS, а не scmRTOS или FreeRTOS ?

Извините, что не сразу ответил.
Тики тикают.
Вопрос решить удалось. Были мои ошибки связанные с оформлением прерываний.
Но в целом пока проект не запустил, возникло много других моментов.

Почему uCOS. Да просто получилось исторически так, что ранее ее использовал для проектов на ARM и все устраивало.
Для MSP430 давно уже применяю scmRTOS(правда так как началось это уже очень давно, то еще версию V2.03) и
тоже было нормально. Находил пару багов, исправлял и все работало.
Но сейчас решил применить опыт работы с ARM (STL:vectore, list, map, string) в MSP430, ну и понадобилось защищать
heap для библиотечных элементов. Для ARM делал это через TLS, а для scmRTOS писал простой диспетчер и всю динамику делал
через него. Но библиотечные элементы через мой диспетчер прогонять очень неудобно, вот и решил поменять ОС.
Правда, как сейчас вижу, возникает много вопросов, в особенности с размером требуемого ОЗУ для heap и с тем что DLIB IAR-MSP430
не поддерживает подсчет размера используемой кучи.
Недавно увидел, что с scmRTOS можно прикрутить аллокатор, в частности bget. Может кто имеет опыт этого, например, сколько потребуется ОЗУ, и
ляжет все это для MSP430F5437A. Может есть какие-то другие решения потоковой защиты библиотечных элементов Heap, которые можно применить с контроллерами у которых
ограничен ресурс ОЗУ.
Использование MSP430F5437A обусловлено требованием малого потребления. Устройство в моем старом проекте в основном режиме потребляет 30мкА.

[jcxz]

Может есть какие-то другие решения потоковой защиты библиотечных элементов Heap, которые можно применить с контроллерами у которых
ограничен ресурс ОЗУ.

Для МК у которых "ограничен ресурс ОЗУ" не нужно применять Heap. Это самое правильное решение.
Ну а если так уж чешется, то что мешает использовать семафоры например? (OSSemPend()/OSSemPost())