Jump to content

    

Подскажите, где почитать как наблюдать за переменными, памятью в дебуггере?

17 минут назад, Forger сказал:

Специально для такого случая: локальные переменные размещаются в стеке (если явно не пытаетесь использовать регистры),

Неправда. Оптимизацию никто не отменял.

Share this post


Link to post
Share on other sites
2 hours ago, jcxz said:

Оптимизацию никто не отменял.

Это не меняет сути - локальные в динамике из-под отладчика ни так ни так все равно не посмотришь.

Тут варианты:

выводить их значения в отладочный порт (swd, usart или еще как-нить) вручную,

копировать их значения в некие глобальные переменные и уже их смотреть в watch,

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

Share this post


Link to post
Share on other sites

Кто подскажет, почему на F407 выпадает это:

Quote

---------------------------
Debugger - Cortex-M Error
---------------------------
This target device does not support conditional breakpoints!
Please remove all conditional breakpoints and start again.
---------------------------
ОК   
---------------------------
 

При попытке запустить дебуггер с установленной conditional breakpoints ? Это действительно не поддерживается процессором? Или St-Link?

Share this post


Link to post
Share on other sites
6 minutes ago, Димон Безпарольный said:

Это действительно не поддерживается процессором?

http://www.keil.com/support/docs/3587.htm

зы Найдено в гугле за 2.24 сек.

 

 

6 minutes ago, Димон Безпарольный said:

Или St-Link?

Купите уже нормальный отладчик, хотя бы клон нормального отладчика. а всякие STлинки оставьте для демобордов, где им самое место.

 

Share this post


Link to post
Share on other sites
On 5/7/2019 at 9:00 PM, Димон Безпарольный said:

. . . .  Конкретизирую. Есть подозрение что в процессе выполнения кода разрушается память.  . . . . 

Сильно рекомендую использовать Call stack окно. Слет мог быть и ДО входа непосредственно в конкретную ф-ю, он лишь проявился на возвратах (один вариант из миллиона возможных причин). Поставьте заглушку на эту ф-ю и проверьте, отрабатывают ли все возвраты "вверх" по стеку.

Отловить где именно код "шалит" можно аналогично - вставкой заглушек + "бинарный поиск".

Если поведение программы в режимах Debug\Release отличаются, возможно влияют "таймерные" участки кода. 

 

 

Share this post


Link to post
Share on other sites
On 5/9/2019 at 8:56 PM, k155la3 said:

Сильно рекомендую использовать Call stack окно. Слет мог быть и ДО входа непосредственно в конкретную ф-ю, он лишь проявился на возвратах (один вариант из миллиона возможных причин). Поставьте заглушку на эту ф-ю и проверьте, отрабатывают ли все возвраты "вверх" по стеку.

Отловить где именно код "шалит" можно аналогично - вставкой заглушек + "бинарный поиск".

Если поведение программы в режимах Debug\Release отличаются, возможно влияют "таймерные" участки кода. 

 

 

Не сочтите за труд - подскажите можно ли в дебаггере определить глубину использования стека. Надеюсь что понятно выразился - нужно для определения значения Stack_Size. Ковыряю чужой код, выставлено Stack_Size        EQU     0x4000. Фантастически много на мой взгляд. Софт не сложный.

Share this post


Link to post
Share on other sites
1 hour ago, Димон Безпарольный said:

Не сочтите за труд - подскажите можно ли в дебаггере определить глубину использования стека. Надеюсь что понятно выразился - нужно для определения значения Stack_Size. Ковыряю чужой код, выставлено Stack_Size        EQU     0x4000. Фантастически много на мой взгляд. Софт не сложный.

Можете на "входах" в функции "лочить" значения регистра стека в массив, который индексируется статической переменной.

В этой методе есть недостатки, но для грубой оценки достаточно.

static int StackLock[100], StackIdx;

#define STACK_LOCK  \
StackLock[StackIdx]; StackIdx++;


void MyFun(void)
{
	. . . . . 
	STACK_LOCK
	. . . . .
}

Можно до main() "залить" сегмент стека константой (например 0x77). Тогда в любой момент можно посмотреть дамп памяти, и посмотреть какая стековая область использовалась.

ЭТО - для простого (не аппаратного) стека, я пользовал для MSP430. 

 

ps

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

 

Share this post


Link to post
Share on other sites
9 минут назад, k155la3 сказал:

Можете на "входах" в функции "лочить" значения регистра стека в массив, который индексируется статической переменной.

Мало что даст, особенно при включении оптимизации: оптимизатор может создавать новые функции, объединяя в них часто используемые куски.

Да и при вызове библиотечных функций - как добавите в них запись SP? А такие как sprintf() могут много стека использовать.

Это уже не говоря о том, что такой способ будет работать только с суперциклом, а с ОС - вообще не будет работать. Да даже в случае суперцикла - если есть функции, вызываемые из фоновой программы и из ISR - тоже не будет работать.

 

Цитата

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

Это уже гораздо лучше.

Share this post


Link to post
Share on other sites
1 minute ago, jcxz said:

Мало что даст, особенно при включении оптимизации: оптимизатор может создавать новые функции, объединяя в них часто используемые куски.

Да и при вызове библиотечных функций - как добавите в них запись SP? А такие как sprintf() могут много стека использовать.

Это уже гораздо лучше.

Я понимаю, все "глубоко индивидуально".  Можно конечно и контрольные точки ставить "на изменение" в области, например, полстека. Далее - по обстоятельствам.

Share this post


Link to post
Share on other sites
4 минуты назад, k155la3 сказал:

Можно конечно и контрольные точки ставить "на изменение" в области, например, полстека. Далее - по обстоятельствам.

Это уже - игра в рулетку. Так как функция может выделить массив на стеке, но не обязательно будет писать во все его ячейки. И контрольная точка, как назло, окажется в такой незаписанной ячейке.

Share this post


Link to post
Share on other sites
10 minutes ago, jcxz said:

. . .  И контрольная точка, как назло, окажется в такой незаписанной ячейке.

Это да. Надо "курить" контрольные точки, в том числе на диапазоны адресов (если такое есть) и на состояние регистра SP (=><).

До сих пор обходился "традиционными" методами  :)

Share this post


Link to post
Share on other sites

Можно поставить RTOS и включить в ней контроль стеков задач. Любая вменяемая RTOS это умеет делать.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now