Ну здрассте. Есть же watchpoint, он же data breakpoint.

А каким образом с его помощью можно контролировать SP или доступ к памяти через SP?
Оно вроде насколько я знаю только контролирует доступ к памяти вне зависимости от регистра из которого была запись/чтение. Или у меня J-Link какой-то урезанный???

Моё дело - предложить, ваше дело - отказаться. Я вижу техническую возможность.
Можете упираться и критиковать - мне всё равно

Да никак, никому это не нужно.

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

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

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

Скажем засекаем метки времени в своем прерывании и делаем останов когда время затянулось дольше обычного.
Правда без таймлайна JLink тут тоже мало толку будет.
Таймлайн это все!

Я вижу саботаж только здесь.
Вы действительно не понимаете сути вопроса или это троллинг?
Мне кажется вопрос кристалльно ясен. Ситуация:
void f()
{
char b[100];
b[0] = некое_выражение;
...
}
Эта функция вызывается когда до границы стека текущей задачи осталось например 50 байт.
Внимание вопросы:
Что будет со стеком и с SP?
Что будет с памятью, находящейся ниже стека текущей задачи?
Каким образом при помощи watchpoint (или каких-то других сервисов) обнаружить факт выхода SP за границы стека текущей задачи (и записи по SP) в такой ситуации?
При условии что в памяти расположенной ниже стека текущей задачи, могут находиться другие переменные, запись в которые через другие регистры (не SP) - штатна, и запись через SP из других задач - штатна, и не должна вызывать срабатывания механизма обнаружения переполнения стека.
В качестве доп. условий: работа идёт в многозадачной среде, есть N задач, каждая со своим стеком.


Если частота его будет такова, что прерывания будут происходить каждые десяток-два команд, то высока вероятность того, что SP уже сбился и выполнение начало куда-то уходить, но содержимое регистров/памяти ещё не успело разрушиться настолько что невозможно найти место где произошло выполнение или CPU вообще не завис.
Т.е. - функция то исправна, и она продолжает выполняться, ну разрушила она чужую память, находящуюся ниже её стека, ну были там адреса возврата, по которым PC улетит в неизвестном направлении, но это случится только когда ОС передаст управление той задаче, чьи данные были разрушены. Это может быть не скоро и до этого успеет сработать ловушка по ВЧ прерыванию, контролирующая SP.

Вот был у нас такой реальный факт переполнения стека:
Проблемный стек, переполнялся только иногда, когда по протоколу обмена устройству приходили только определённые запросы от клиента в заранее непредсказуемое время, которые обрабатывались задачей обработки протокола обмена сессионного уровня. Ниже проблемного стека находилась область памяти связных блоков данных (построенная типа массива блоков фиксированного размера, выделяемых динамически по запросу драйверов каналов связи). В эти блоки драйвера каналов связи писали входящие кадры протокола обмена (и исходящие тоже).
Устройство может работать по нескольким каналам связи одновременно, все драйвера каналов связи асинхронны друг к другу.
Симпотмы проявления: иногда почему-то устройство не отвечало на запросы клиента, причём совершенно произвольно - то всё ок, то какие-то запросы почему-то терялись. Хотя канал связи - идеальный, помех не должно быть.
И вот как тут можно было решить, что переполняется стек одной из задач? И как обнаружить проблемное место куда надо вставить этот диагностический код?


Это Вы про то что я писал про контроль длительности запретов прерываний? Ну так у меня это примерно так и работает, только не надо ставить такие метки в каждое прерывание, убирать их и пр. гемор. Просто разрешается некий #define, начинает работать ВЧ прерывание, выполняющееся на высшем приоритете, и оно измеряет временные интервалы между своими вызовами и если есть преывешние - ахтунг! - попадаем в ловушку.
В любой момент когда возникло подозрение можно этто define включить и проверить. Это просто. Хочется чтобы и контроль стека включался так же просто.

У меня было впечатление, что вы человек достаточно опытный в этих делах. Если не можете сами ответить на эти вопросы - что ж, у меня было неверное впечатление, должно быть.

Коллеги, давайте жить дружно!
Хочется помочь - помогите, нет желания - промолчите.

Ситуация совершенно не реалистичная.
Разработчик под RTOS никогда так не сделает. И вы наверняка так не делаете, ибо эти грабли быстро все понимают.
Здесь либо используется динамическое выделение, либо массив делается глобальным, либо разработчик сразу же тестирует этот код на переполнение стека.

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




А это делается в несколько ходов.
Сначала вставляется лог приема-передачи пакетов.
Потом по логу обнаруживается несоответствие поведения.
Находится машина состояний ответственная за соответствующее поведение.
Потом вставляются в ветви состояний команды типа ITM_EVENT(можно даже с аргументом в виде значение стека) и вставляется код с остановом с идентификацией аномального поведения.
И в таймлайне после останова уже смотрят какие прерываний были, сколько длились и какие состояния автомата предшествовали.
Если как в вашем случае обнаруживаем искаженные данные, то ставим на них watchpoint. И все!
На следующем прогоне видим кто (какая задача, процедура, функция ..) портит данные.

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

У меня ошибок стека уж не помню сколько лет не было.

Ну Вы прямо, как в анекдоте с объявлением на столбе - "Могу обучать игре на баяне, английскому языку, использованию watchpoint, но не хочу".


Соглашусь. Проектировать задачи так, что на стеке выделяются здоровенные куски памяти это системная ошибка . Нежели задачи и функции изначально написаны более-менее ровненько по отношению к использованию стека, то не будет ни пиковых потреблений стека ни проюлем с их ловлей в неведомые моменты.

Могу рассказать анекдот про вас, но не хочу

Вообще-то это Ваш совет был использовать watchpoint-ы для обнаружения случаев переполнения.
Я знаю что такое watchpoint, но не приложу ума как его можно использовать в такой задаче.
Если Вы реально хотите посоветовать, так посоветуйте. Если просто хотели показать какой умный - лучше пройдите мимо.

Разве не очевидно?
Настраивать watchpoint на область памяти некоторого разумного размера за стеком, куда полезут данные при переполнении. Настраивать в переключалке задач, чтобы контролировать актуальный стек. Стеки разместить с нужным выравниванием, чтобы всё это было возможным.
Я не пойму, это какие-то непостижимые секреты мироздания?

Не понимаю... В чём её нереалистичность??? Под RTOS нельзя объявлять массивы на стеке?


Попробуйте иногда заглядывать в результирующий асм-код после компилятора.
При выделении стекового фрейма на входе функцию, компилятор удаляет этот фрейм только при выходе из функции. По-крайней мере и IAR и CCS так генерят.
И такой супервизор может пропустить это только если выход случится быстро после входа, что маловероятно (хотя вполне возможно - такой способ не даёт 100%-гарантии обнаружения).


Очень сложно и громоздко.
Представьте что этот сбой происходил не каждый раз при тестировании, а только иногда редко, выявлялся установкой на прогон нескольких устройств и их кргулосуточной работой.
Просто он проявлялся при попадании определённых запросов от клиента в определённые времена работы ПО, что происходило редко и недетерминированно по времени.
Это придётся кучу логов перелопатить и watchpoint-ы не помогут - много устройств - неужто на каждый комп с JTAG-ом ставить?


char b[100] - это только для примера. Если там будет char b[10] - легче что-ли?
Или например - просто вызов sprintf()


Какой для этого J-Link нужен? Мой J-Link не умеет "Настраивать watchpoint на область памяти", а только на конкретный адрес. Ну можно конечно выровнять стек на границу степени 2 и настроить на адреса ниже воспользовавшись маской адреса. Но это тогда куча ОЗУ на это понадобится дополнительного.
А её просто нет. У нас проект уже большой, там ОЗУ не хватит уже даже на массив из нескольких десятков байт, не то что выровнять все стеки всех задач (их около 10) да ещё выделить ниже каждого по приличному куску памяти.
Если-б у меня было столько памяти, я бы просто задействовал MPU: при входе в задачу стек в отдельный регион с разрешением для него, для BSS - другой регион с защитой и т.п. И все регионы на расстоянии друг от друга. Я об этом писал ещё в самом начале топика.
И во-2-ых - события переполнения могут происходить редко и приходится ставить несколько устройств на длительный прогон. И нет возможности сидеть над каждым устройством с JTAG-ом.

О господи. Эти самые watchpoint можно настраивать через регистры без всяких жтагов.

Не сочиняйте.
При 10 задачах у вас должно быть море лишней памяти если вы не делали статический анализ стека.