Как определить максимальную реальную глубину CSTACK моей программы?, в отладчике Опции

[Разработчики]

Есть ли какая-нибудь встроенная особенность отладчика IAR, которая автоматически показывает максимальную глубину CSTACK, которая произошла в моей программе за время отладки встроенным отладчиком?

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

Думаю, вопрос подойдет про разные платформы. Конкретно - AVR.

Сообщение отредактировал Разработчики - Oct 14 2015, 08:36

[Непомнящий Евген...]

Заполняете область стека неким шаблоном (0xff, 0xDEAD, etc) и смотрите, где шаблон нарушен - туда опускался стек

[Разработчики]

Заполняете область стека неким шаблоном (0xff, 0xDEAD, etc) и смотрите, где шаблон нарушен - туда опускался стек

Да, сейчас так и делаю. Даже можно ничем не заполнять, потому что само заполняется ненулями.
Но может есть что-то встроенное.

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

Можно попросить линкер построить дерево вызовов и сложить глубину основного цикла с максимальной глубиной обработчиков прерываний. Вообще без отладчика.

[Разработчики]

Спасибо. Я посмотрел, он довольно сильно завышает.

А можно как-то из программы определить границы (начало и конец) SCTACK - где расположено?

Сообщение отредактировал Разработчики - Oct 14 2015, 11:22

[jcxz]

Можно попросить линкер построить дерево вызовов и сложить глубину основного цикла с максимальной глубиной обработчиков прерываний. Вообще без отладчика.

Не канает если есть косвенные вызовы.

А можно как-то из программы определить границы (начало и конец) SCTACK - где расположено?

Стек в программе не определяют, а задают. Если что. Так же как любой другой массив.

[den_po]

А можно как-то из программы определить границы (начало и конец) SCTACK - где расположено?

__segment_begin("CSTACK")
__segment_end("CSTACK")

и нужно не забыть заранее сделать так:
#pragma segment = "CSTACK"

[Разработчики]

и нужно не забыть заранее сделать так:
#pragma segment = "CSTACK"

Я имел в виду системный сегмент CSTACK, а не мой.

Стек в программе не определяют, а задают. Если что. Так же как любой другой массив.

Для массива можно из программы узнать, куда его запихал компилятор. А CSTACK?

[den_po]

Я имел в виду системный сегмент CSTACK, а не мой.

Они оба - один и тот же сегмент. Просто сишный компилятор не знает о нём, если ему не подсказать.

[Разработчики]

Они оба - один и тот же сегмент. Просто сишный компилятор не знает о нём, если ему не подсказать.

Понял. Спасибо!

[jcxz]

Для массива можно из программы узнать, куда его запихал компилятор. А CSTACK?

Я не знаю, что в Вашей программе означает символьное имя CSTACK. Это только Вы можете знать. В моих проектах это имя не используется.
У меня есть массив
static __root __no_init OS_STK stkTaskMain[NNN + STK_SIZE_ISR_NFP] @ ".bssStkMain";
задающий стек используемый стартапом и функцией main() (и, впоследствии, после старта ОС, другой задачей), есть сегмент .bssStkMain, в который линкуется этот массив и указатель на конец которого записывается в вектор сброса.
Есть множество других стеков задач ОС, каждый задан массивом типа
__no_init static OS_STK stkXXX[NNN + STK_SIZE_ISR_NFP] @ ".bssStk";
И место под любой стек задаётся статическим массивом в исходниках либо в файле конфигурации компоновщика (*.icf в IAR).

[den_po]

Я не знаю, что в Вашей программе означает символьное имя CSTACK. Это только Вы можете знать. В моих проектах это имя не используется.

То есть вы НИКОГДА не использовали иаровский стартап и его же конфиги линкера по умолчанию?

[jcxz]

То есть вы НИКОГДА не использовали иаровский стартап и его же конфиги линкера по умолчанию?

Когда-то давно использовал. Но это было давно. Последние годы использую везде (в ARM) только свои стартапы.

[Target]

А подскажите, как получить трехбайтовую величину? Хочу получить длину программы по окончанию сегмента NEAR_ID.
Пытаюсь получить адрес сегмента NEAR_ID.

Делаю так:

#pragma segment = "NEAR_ID"
unsigned long * pNEAR_ID_end = (unsigned long *)__segment_end("NEAR_ID");


Компилятор ругается так:

Linking
Warning[w47]: Range error,
Number out of range. Valid range is -128 (-0x80) to 255 (0xFF).
File: main.cpp, Line: 247
Source: LDI R17, (SFE(NEAR_ID)) >> 8

Если вместо unsigned long ставить void или word, то выдает только 2 байта, а третий - ноль.

[SSerge]

А подскажите, как получить трехбайтовую величину? Хочу получить длину программы по окончанию сегмента NEAR_ID.
Пытаюсь получить адрес сегмента NEAR_ID.

Очень похоже на то, что сказывается гарвардская архитектура AVR. Указатели на память данных и память кода это две совершенно разные сущности и просто так не смешиваются.
А у Вас как раз написано unsigned long * pNEAR_ID_end = ..., что подразумевает указатель на память данных, в то время как сегмент NEAR_ID располагается во флеше.
В EWAVR_CompilerReference.pdf есть подсказка:

If the segment was declared with a memory attribute
memattr, the type of the __segment_begin operator is a pointer to memattr void.
Otherwise, the type is a default pointer to void.

Попробуйте так:
#pragma segment = "NEAR_ID" __farflash
char __farflash* pNEAR_ID_end = __segment_end("NEAR_ID");
а то и просто
uint32_t pNEAR_ID_end = __segment_end("NEAR_ID");

[Ga_ry]

Что то читал, читал эту ветку и так и не понял как определить хватает места программе для стека или нет.
Вот например (IAR AVR) изначально по умолчанию 0x20 явно не хватало, шли сбои, увеличил до 0x44
вот последние строчки из MAP

CSTACK DATA 00000100 - 00000144 45 dse 0
RSTACK DATA 00000145 - 00000178 34 dse 0
NEAR_I DATA 00000179 - 00000284 10C rel 0
NEAR_Z DATA 00000285 - 000002DF

во вложении скриншот memory data после работы программы

Как понять сейчас хватает программе этого размера?
Какой минимум можно оставить для CSTACK?



Сообщение отредактировал Ga_ry - Nov 25 2015, 19:31

[kolobok0]

...Как понять сейчас хватает программе этого размера?Какой минимум можно оставить для CSTACK?..

делаете три вещи
1) при выделении стэка расписываете магическим числом всю память под стэк.
2) в определённые срезы времени проверяете сколько памяти осталось расписанной вашим магическим числом(например при переключении задач, если ось)
3) скидываете каждые изменения размеров остатков стэков в лог

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

[Ga_ry]

Понятно.
Вот только логи мне писать некуда, 8к почти под завязку (20 байт осталось) т.е. код для формир. лога вставить тоже некуда. Ноги МК тоже, НИ ОДНОЙ свободной.
Брать контроллер с большей памятью, отладку делать на нем?

А вот это изначальное заполнение FF не пойдет для магического числа?

[Target]

#pragma segment = "NEAR_ID" __farflash
char __farflash* pNEAR_ID_end = __segment_end("NEAR_ID");

Спасибо!

Помогло так:

#pragma segment = "NEAR_ID" __farflash
void __farflash * pNEAR_ID_end = __segment_end("NEAR_ID");

А вот это изначальное заполнение FF не пойдет для магического числа?

Обычно там 00. Можно в прерывании по таймеру или кнопке искать адрес первого ненулевого байта.

[Ga_ry]

Обычно там 00.

Странно, в скриншоте, который прикреплен, видно FF

[kolobok0]

...изначальное заполнение FF не пойдет для магического числа?

20 байт - можно использовать для многого под отладчиком для просмотра/контроля - вполне.
а вот FF - тут дело такое. для скорости проверки необходимо брать всю разрядность шины данных. т.е. если у вас используются 32 разрядный мк -
то это уже 4 байта за раз можно писать/тестировать/сравнивать...

нолик 0x00 как и минус один(в стандарте сей) 0xFF чаще встречается чем какие-либо другие комбинации.

[Ga_ry]

kolobok0, а зачем надо умножать на два?

[x893]

а разве DEADBEEF не помогает - или религия запрещает ?
проблема из пальца выдуманная

[kolobok0]

kolobok0, а зачем надо умножать на два?

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

[Ga_ry]

а разве DEADBEEF не помогает - или религия запрещает ?
проблема из пальца выдуманная

Этот Ваш стиль надменно-пренебрежительный это врожденное или приобретенное?
Ссылку дайте, я первый раз слышу о таком.

[k155la3]

делаете три вещи
1) при выделении стэка расписываете магическим числом всю память под стэк.
2) в определённые срезы времени проверяете сколько памяти осталось расписанной вашим магическим числом(например при переключении задач, если ось)
3) скидываете каждые изменения размеров остатков стэков в лог

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

В ОС (из-за многостековости) имеются "включаемые" режимы контроля размера стек(ов).
Алгоритм тот что указан выше.

freeRTOS:

Код

#if( configCHECK_FOR_STACK_OVERFLOW == 1 )

    /* FreeRTOSConfig.h is only set to use the first method of
    overflow checking. */
    #define taskSECOND_CHECK_FOR_STACK_OVERFLOW()

#endif