Использую uCOS-II под ATMEGA128.
Сначала, когда проэкт минимальный ошибки нет. После увеличения програмного кода компилятор выдает такую ошибку:
General options->Target->Configure system using dialogs (not in .xcl file) галочка убрана(когда стоит ОС не работает).

//----------------------------------------------------------------------------
Error[e16]: Segment CSTACK (size: 0x200 align: 0) is too long for segment definition. At least 0x6 more bytes needed. The problem
occurred while processing the segment placement command
"-Z(DATA)CSTACK+_..X_CSTACK_SIZE=_..X_SRAM_BASE-_..X_SRAM_END", where at the moment of placement the available
memory ranges were "DATA:f06-10ff"
Reserved ranges relevant to this placement:
DATA:100-2c0 NEAR_I
DATA:2c1-ec5 NEAR_Z
DATA:ec6-f05 RSTACK
DATA:f06-10ff CSTACK
Total number of errors: 1
Total number of warnings: 0
//----------------------------------------------------------------------------

На сколько я понимаю не хватает ОЗУ для стеков. Когда галочку устанавливаю то этой ошибки нету. При выключеной галочке я не могу указать размер внешней памяти (окно General options->System не активно).

Подскажите кто знает:
1. С чем связана данная ошибка и как ее устранить ?
2. Возможно ли использование в данной ОС внешнего ОЗУ ?

Может это поможет?

Меню Project->Options->General Options вкладка Target

Установить Memory model = small

Дальше, перейти на вкладку System и установить необходимые размеры стеков CSTACK и RSTACK.

По крайней мере, мне это помогло, ошибка была такая же, только проект был не на ОС, а просто самостоятельная программа.

Либо внимательно почитав руководство по линкеру в плане опций *.xcl файла самому найти в последнем ошибку и вручную исправить.
Дело может быть в следующем.
Обычно стековые сегменты стоЯт в адресном пространстве ОЗУ последними и если им не хватило места, значит стоЯщие ранее сегменты его слишком много отхватили.
Делать надо следующее:
1. уменьшить таки размеры стеков (в специальных для этого константах *.xcl файла);
2. выявить неоправданно большие источники расхода ОЗУ (огромные массивы, особенно многомерные).
Попытаться собрать более простой проект - пусть сначала просто соберётся без ошибок и просмотреть файл *.map, выдаваемый линкером (эту опцию надо разрешить в настройках линкера) на предмет выяснения источников потребления памяти.
По мере усложнения проекта следить за потреблением памяти не допуская её дефицита. В случае возникновения последнего - перейти к использованию динамического выделения памяти, но это уже высший пилотаж.

Удачи.

Ещё кое-какие соображения.
У Вас сильно потребляется обнуляемый сегмент . Видимо это стеки процессов. Уменьшите их размеры. Лучше если они будут не просто одинаковыми, а по необходимости.
Второе - постарайтесь обойтись меньшим количеством процессов.
Третье - в случае применения ОС основные стеки системы RSTACK, CSTACK можно уменьшить, т. к. основная работа идёт в стеках процессов.
Последнее - внешнюю память применять можно, но:
- это медленнее, поэтому стеки процессов и основной стек надо держать во внутренней;
- придётся конфигуритровать *.xcl файл с учётом внешней памяти;
- придётся включить эту память в модуле __low_level_init() (файл low_level_init.c).

Спасибо.
Буду разбираться с линковочным файлом. Хотя в примере, который из потром идет *.xcl файл не используется.
Еще заметил вот такой спецефект:
Сначала работало 3 потока, ошибок не возникало. Потом после первой ошибки я размер стека уменьшил для всех потоков.
Теперь уже 2 потока, маленький размер стека, выключил громоздкие вложенные ф-и и все разно возникает ошибка
Наверно компилятор без *.xcl файла выделяет ОЗУ произвольно, бо я вообще никакой зависимости не уловил.

Потребление памяти каждой единицей компиляции (файл *.c или *.cpp) до линкования можно увидеть в *.lst файлах (их создание надо разрешить в опциях компилятора).
В конце каждого такого файла есть суммарная информация.

Правда, размер кода в них не характеризует реальное потребление памяти программ, т.к. в .lst файлах приводится размер кода всего скомпиленного в файле, а в слинкованный файл включается только используемое.

Более того, стековая картинка не учитывает потребление стека вложенными функциями, скомпилированными не в текущем файле.