Помогите, пожалуйста, советом!
Столкнулся с непонятными эффектами при работе IAR AVR с отладчиком JTAG-ICE.
При вызове одной из функций в программе происходит выпадение отладчика. То есть, работа как бы продолжается, но при попытке останова появляется следующее сообщение:
Tue May 13 16:35:37 2008: The stack 'CStack' is filled to 100% (1024 bytes used out of 1024). The warning threshold is set to 90%.
Tue May 13 16:35:37 2008: The stack 'RStack' is filled to 100% (1024 bytes used out of 1024). The warning threshold is set to 90%.
Tue May 13 16:35:37 2008: The stack pointer for stack 'CStack' (currently DATA:0x00FFFF) is outside the stack range (DATA:0x000100 to DATA:0x000500)
Tue May 13 16:35:37 2008: The stack pointer for stack 'RStack' (currently DATA:0x00FFFF) is outside the stack range (DATA:0x000500 to DATA:0x000900)
При этом ранее все то же самое работал и с куда меньшим размером стека. Что удивительно для превышения размеров стека - плата с прошивкой совершенно нормально работает и далее. А вот отладчик уже ничего сделать не может. Сама процедура тоже не исполняется. Чем это может быть вызвано - ума не приложу Сейчас попробую откатиться на более старую версию, посмотрю, как это функционировало там. Процедура, которая вызывает сбой, имеет следующий синтаксис:
TBool Print_Report(TReport __flash *PrReport);
typedef struct
{
char name_fmt[80];
TByte type;
} TReport;

Если у кого будут идеи - с удовольствием их выслушаю!

Версия IAR AVR - 4.21A/W32 (4.21.0.3)

Сообщение отредактировал Polaris - May 13 2008, 14:00

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

А как это понимать? Можно подробнее, пожалуйста?

Как понимать? Так и понимать, что имеется право создавать собственные отдельные стеки. Это, например, операционки создающие собственные стеки для каждой из задач. В некоторых случаях/архитектурах обработчики прерываний...

Это не операционка

Оно вам четко написало: Вот и разбирайтесь, почему в указатель стека попало число 0xFFFF. Ходите по шагам, найдите участок, где это происходит, пройдите его по дизассемблерному листингу.

Подобные предупреждения у меня встречались когда пытался создать статический локальный объект, для которого по мнению компилятора не хватало места в стеке. На железе тем не менее все работало. Переместив его в кучу (heap), сделав динамическим, предупреждения ушли. Мджет у вас нечто подобное.

Не могу пройти по шагам, тут дело, видимо, даже не в вызове конкретной процедуры. Только что получил такое же сообщение, просто остановив отладчик. Плата при этом работает нормально. Так что дело совершенно определенно не в том, что кто-то переполняет стек, нет такого. Дело именно в ошибке, инициируемой самим отладчиком JTAG-ICE.

Вы попробуйте воспльзоваться родным симулятором IAR или Студией, я думаю у вас будут те же самые ворнинги. ИМХО JTAG здесь не причем. Выбросите или "зашунтируйте" куски программы которые явно зависят от "железа", и вперед по шагам, как рекомендовал Сергей Борщ.

Всем спасибо, проблема вовсе не в IAR и не в перерасходе стека. Опытным путем выяснилось, что подобное поведение отладчика вызывалось статическими разрядами (что-то на мне они начали в последнее время накапливаться ) Как только проскакивает искра между мной и платой - с высокой степенью вероятности отладчик отваливается с подобными сообщениями на выходе из режима отладки.

Потеряна связь с чипом. У меня такое происходит когда UPS щелкает, или включается что-то мощное рядом с отлаживаемым девайсом.


Сори что с опозданием, постили бы в AVR форум, ответил бы в день вашего сообщения. А так эти новые "экзотические" подфорумы по IAR и GCC вообще заметил только сегодня.

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