В проекте на 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.

Программируя 16-Bit Ultra-Low-Power Microcontroller, 256KB Flash, 16KB RAM, 12 Bit ADC, 2 USCIs, 32-bit HW Multi
на ассемблере, можно очень многого добиться. Примените более простое решение для достижения результата.

Тики тикают ? Проверьте не на отладчике, а аппаратно, методом ногодрыга.
Неполиткорректный вопрос. Почему 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мкА.

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

А для чего же тогда куча придумана, как не для использования "ограниченного ресурса ОЗУ"?

для MSP430 16k - это не "ограниченный ресурс", это даже много
И чтоб его заполнить (эффективно-полезно) проект должен быть большой (по коду-алгоритму).
Или - Вы делаете нечто вроде мобильного (на батарее) сервера, каждое из подключений будет "кушать" RAM.

Для систем где этот ресурс можно считать неограниченным, естественно. Как только этот ресурс становится ограниченным, вылазят все проблемы связанные с кучей.


Приложение из пары тысяч строк, выводящее некую инфу на пиксельный LCD разрешением скажем 320x240 при 4х цветах - это большой проект?
А ведь всего-то потребует порядка ~38КБ только под видеобуфер в ОЗУ....
Или например: простой логгер (может даже меньше 1000 строк) пишущий всего пару параметров в журнал находящийся в большой внешней флешке с размером блока стирания 128КБ, но с необходимостью изредка корректировать записанные данные в середине журнала. А значит нужен буфер 128КБ чтобы считать/скорректировать/стереть/записать.
Имхо: много или мало ОЗУ определяется не архитектурой (MSP430, ARM, etc.), а задачей.