Перейти к содержанию
    

uCOS-II под ATMEGA128. Ошибка "Error[e16]: Segment CSTACK..."

Использую 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, выдаваемый линкером (эту опцию надо разрешить в настройках линкера) на предмет выяснения источников потребления памяти.

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

 

Удачи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ещё кое-какие соображения.

У Вас сильно потребляется обнуляемый сегмент

DATA:2c1-ec5 NEAR_Z

. Видимо это стеки процессов. Уменьшите их размеры. Лучше если они будут не просто одинаковыми, а по необходимости.

Второе - постарайтесь обойтись меньшим количеством процессов.

Третье - в случае применения ОС основные стеки системы RSTACK, CSTACK можно уменьшить, т. к. основная работа идёт в стеках процессов.

Последнее - внешнюю память применять можно, но:

- это медленнее, поэтому стеки процессов и основной стек надо держать во внутренней;

- придётся конфигуритровать *.xcl файл с учётом внешней памяти;

- придётся включить эту память в модуле __low_level_init() (файл low_level_init.c).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо.

Буду разбираться с линковочным файлом. Хотя в примере, который из потром идет *.xcl файл не используется.

Еще заметил вот такой спецефект:

Сначала работало 3 потока, ошибок не возникало. Потом после первой ошибки я размер стека уменьшил для всех потоков.

Теперь уже 2 потока, маленький размер стека, выключил громоздкие вложенные ф-и и все разно возникает ошибка :(

Наверно компилятор без *.xcl файла выделяет ОЗУ произвольно, бо я вообще никакой зависимости не уловил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

В конце каждого такого файла есть суммарная информация.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

В конце каждого такого файла есть суммарная информация.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...