Доброго всем дня ! Подскажите пожалуйста, что делаю не так. Имеется IAR 4.40A. На вкладке Options/
Linker/Config указываю в качестве Linker Command File свой файл, в котором инициализирую стек следующим образом :

//*************************************************************************
// Stack and heap segments.
//*************************************************************************

-D_CSTACK_SIZE=2000
// -D_SVC_STACK_SIZE=10
-D_IRQ_STACK_SIZE=100
-D_HEAP_SIZE=2000

-Z(DATA)CSTACK+_CSTACK_SIZE=RAMSTART-RAMEND
// -Z(DATA)SVC_STACK+_SVC_STACK_SIZE=RAMSTART-RAMEND
-Z(DATA)IRQ_STACK+_IRQ_STACK_SIZE,HEAP+_HEAP_SIZE=RAMSTART-RAMEND

При отладке с самых первых шагов выскакивает предупреждение:

Mon Apr 23 14:16:34 2007: The stack 'CSTACK' is
filled to 97% (7964 bytes used out of 8192). The
warning threshold is set to 90%.

Откуда на 'CSTACK' берется 8192 байта, если в файле указано 2000? И почему так быстро забивается стек? Возможно я чего-то не понимаю.
Обьясните пожалуйста идиоту.....

Стал копаться в опция линкера, и на той же вкладке нашел Comand file configuration tools. В выскочившем окошке в качестве адресного диапазона INTERNAL ROM указан диапазон 8000-FFFFF, а в качестве диапазона INTERNAL RAM -100000-7FFFFF - это при том, что используется МК LPC2214 ( ROM - 00000000 - 0003FFFF, RAM - 3FFFFFFF-40003FFF ), хотя в качестве таблицы векторов указаны адреса 0x0 - 0x3f, что соответствует действительности... . На следующей вкладке этого окна в качестве HEEP SIZE указан объем 8000,а не 2000 , как в вышеупомянутом файле....

Возможно вопросы глупые, но все же обьясните пожалуйста, что используется для распределения памяти, и почему в Comand file configuration tools такое распределение адресов?
Спасибо...

0x2000 = 8192 (десятичное).
Может тут собака порылась?
Про IAR не знаю.

Пожалуй фраза про идиота и не такая уж и смешная........ Ладно, почему тогда так быстро забивается стек ?

Действительно, линкер вомпринимает числа в опциях как шестнадцатеричные. К ним можно приписывать 0x как напоминание.
В опциях линекера Command Line Configuration Tool работает как-то непонятно. Откуда берёт входные данные - неясно. Ясно, что результат пишет в файл. Я бы лучше этот файл руками правил.
Посмотрите в .MAP файл, чтобы проверить, какого размера и где линкер разместил стек. Потом пройдите отладчиком по инициализации стека в cstartup и убедитесь, что инициализация правильная.
При предупреждении проверьте самостоятельно занятость стека. Может быть, отладчик неправильно воспринимает размер стека? Если стек действительно занят, можно при помощи JTAG и WATCHPOINT установить, какой код туда пишет.

А еще, на сколько я помню, 0x2000 + 0x2000 равно объему RAM (16К) для LPC2214.
Может это не проблема стека, а проблема нехватки RAM?

Сталкивался с подобным на RM9200, тот же IAR. Область стека специально проверял - забито не более чем несколькими вложенными вызовами. Одна из фич, которые к такому приводили - размещение локальных буферов в main (их размер + вложенные вызовы много меньше размера выделенного стека). После перенесения их за пределы main - подобное предупреждение исчезло. Фича или глюк - но имело место быть.

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

потому что для линкёра вы всё значения в 16ричной системе должны указывать.
2000(HEX) = 8192(DEC)

to cf7k и IgorKossak :

Да, действительно, Вы оказались правы. В main были размещены локальные буфера - работали на прием данных из стека Wiznet...

Большое всем спасибо!

И что в этом случае надо делать?

Думать, а влезут-ли они в отведенный стек. И если не влезут думать что делать со стеком или буферами, или контроллером

Добавлю свои три копейки:
Для анализа размеров получившегося бинарника - вообще-то можно после линковки посмотреть в файл *.map - мне что-то подсказывает, что IAR его тоже делает... Наверное интуиция...

Локальные обьекты в *.map файле не отражаются, а ведь из-за них основной сыр-бор в данном топике.
Более полезную информацию в данном случае могут дать *.lst файлы, т. к. в них есть информация о потреблении стека функциями.

У меня наблюдалось странное переполнение R стека при вызове vsprintf (на IARAVR 4.20A + mega128), вылечилось сиё дело включением оптимизации (максимальная оптимизация по размеру). С С стеком при этом было всё нормально.