[jcxz 182]

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

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

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

[Forger 17]

2 hours ago, jcxz said:

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

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

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

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

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

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

[Димон Безпарольный 2]

Кто подскажет, почему на 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?

[Forger 17]

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

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

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

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

 

 

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

Или St-Link?

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

 

[k155la3 26]

On 5/7/2019 at 9:00 PM, Димон Безпарольный said:

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

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

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

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

 

 

[Димон Безпарольный 2]

Спасибо за советы. Ошибка найдена - неправильный адрес назначения DMA пересылки. 

[Димон Безпарольный 2]

On 5/9/2019 at 8:56 PM, k155la3 said:

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

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

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

 

 

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

[k155la3 26]

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

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

 

[jcxz 182]

9 минут назад, k155la3 сказал:

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

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

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

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

 

Цитата

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

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

[k155la3 26]

1 minute ago, jcxz said:

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

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

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

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

[jcxz 182]

4 минуты назад, k155la3 сказал:

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

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

[k155la3 26]

10 minutes ago, jcxz said:

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

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

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

[Forger 17]

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