Интересно - есть-ли у IAR возможность вставки префикса в начало каждой функции при компиляции?
Т.е. - чтобы после входа в каждую функцию в проекте, после PUSH, он вставлял некий фиксированный код (hook). Возможно это несколько ассемблерных строк или просто вызов функции BL (естественно с предварительным сохранением исходного LR на стеке). Видел такую возможность у какого-то компилятора, не помню точно, но вроде у CCS.
Думаю добавить в проект функционал контроля стеков задач. И думаю как это удобнее всего сделать. С помощью такого хука это можно было-бы реализовать.

В яре такого вроде не было, лично я так и не нашел. Такое точно есть в гцц. Совсем недавно натыкался на бложик с описанием такого механизма. Там его применяли для построения стека вызовов

А в idle задаче не хотите делать такую проверку?

Во-первых: в idle-задаче у меня выполняется WFE.
Во-вторых (и главное): в idle-задаче управление находится когда все задачи находятся в ожидании семафора, майлбокса, ... или просто выполняя sleep(N-секунд). Т.е. - когда ничем не заняты. А наибольшее использование стека происходит как раз когда задача что-то делает.

Да, вроде, ни первое ни второе не помеха хорошему танцору. Забейте стек шаблоном и проверяйте его. А как закончите проверку, сразу в спячку.

Забитие шаблоном - не лучший метод. Так как стек успеет переполниться, ПО повиснет, а я об этом так и не узнаю. Не говоря уже о ненулевой вероятности совпадения записываемых данных с шаблоном.
Был бы в Cortex-M более функциональный MPU, сделал бы на нём.
А так: или префикс в начало каждой функции или периодическая проверка в ISR высокочастотного таймера. Других способов не вижу пока.

В ассемблерном листинге заменить все BL на запрещённый опкод (уж это, наверное, можно автоматизировать). Далее обрабатывать исключение на invalid opcode.

J-Link Pro в IAR показывает полную пирамиду вызовы в реальном времени в окне timeline.
И весь перечень вызовов в любой точке останова в окне Call Stack.
Если применить MQX то будет отображаться стек вызовов для каждой задачи отдельно.
Также будет виден максимальный расход стека для каждой задачи.
Также покажет автоматически все повреждения служебных структур RTOS.
Покажет и переполнение менеджера памяти и фрагментацию памяти.

И что это даст? Мне нужно максимальное использование стека. По всем задачам.


У меня не MQX. И как интересно MQX это вычисляет? Периодически анализируя затёртость шаблона в отдельной сервисной задаче? Плохо, так как это никак не спасает при переполнении стека.
Я прекрасно понимаю, что заполняя стек шаблоном, можно с большой долей вероятности оценить глубину использования стека. И собственно так сейчас и делаю. Но это работает, только если нет случаев переполнения стека!


Ну да. А ещё BLX. А ещё и все B проанализировать, так как они тоже могут являться вызовами функций (если такой вызов находится в конце другой функции).
Да и что потом с этим листингом делать? Как из него прошивку получить?
Заменять тогда уж надо не BL, а все PUSH и SUB SP,#...

да простят меня ....
переобразовать return в Return по тексту проекта или тамгденадо


С аргументом для ret надо вывернуться и для void f() всеравно писать return.

Сообщение отредактировал k155la3 - Aug 3 2016, 13:18

Да. Это опция компилятора/линкера -pg
Можно почитать про mcount и profile hook.
Наверняка какой то профайлер и для яра имеется.

Ну да:
void func1() { func2(); }
void func2() { func3(); }
void func3() { func4(); }
...
А теперь представьте, что переполнение стека произошло ещё в func1(). До func4() (где Вашим способом это можно будет обнаружить) дело уже может и не дойти, так как к этому времени перепахает полпамяти.
Да и очень желательно всё-же оставаться в синтаксисе языка си, который не обязывает ставить return в таких функциях.
К тому же: не все функции, которые будут в результирующем коде, присутствуют в исходниках (оптимизатор тоже может сам генерить функции).
Я уже не говорю, что "вывернуться с аргументом для ret" получится далеко не для всех аргументов.
И вообще - надо чтобы си-исходник оставался обычным читаемым си-исходником, а не некоей тарабарщиной на непонятном языке.

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


Вот потому и спрашиваю. Прошерстил мануал IAR-а - не нашёл подходящего. Может плохо искал.....

Вот и повод перейти на gcc)))
Я уже давным давно на gcc подсел - ни разу не пожалел.

Ну и как минимум теперь тратите вдвое больше времени на отладку.

А идея про вставку хуков довольно наивна. В либы все равно хуки не вставить.
Да и будет повод для появления ошибок Гейзенберга.

Сделаю вид, что не заметил вашего комментария.