[Polaris 0]

Помогите, пожалуйста, советом!

Столкнулся с непонятными эффектами при работе 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)

Изменено 13 мая, 2008 пользователем Polaris

[zltigo 1]

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

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

[Polaris 0]

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

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

[zltigo 1]

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

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

[Polaris 0]

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

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

[Сергей Борщ 129]

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

Оно вам четко написало:

pointer for stack 'RStack' (currently DATA:0x00FFFF) is outside the stack range (DATA:0x000500 to DATA:0x000900)

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

[VladimirYU 0]

Помогите, пожалуйста, советом!

Столкнулся с непонятными эффектами при работе 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)

 

 

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)

 

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

[Polaris 0]

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

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

[VladimirYU 0]

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

 

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

[Polaris 0]

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

[defunct 0]

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)

 

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

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

 

Опытным путем выяснилось, что подобное поведение отладчика вызывалось статическими разрядами

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

[Polaris 0]

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

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

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