А зачем ему считать остановленным? Ждем когда досчитает до нужного значения, тут и останавливаем, смотрим что да как. Вообще, можно по всякому извернутся. Но отладка по сообщениям в терминале тот еще ад, требующий постоянных правок и перепрошивок. С внутрисхемным отладчиком можно прямо по ходу выполнения программы нужные значения изменить у регистров и переменных.

У кого как. У меня основные проблемы обычно вызывает какая-нибудь логика более высокого порядка. И ее как раз-таки удобно отлаживать сообщениями. Да те же цепи конечных автоматов: сидишь, вроде бы должно быть так, а у тебя — эдак. Смотришь — а определенное состояние просто пропускается. Лезешь в код: ба, да забыл при копипасте сменить имя состояния ☺
А как это отладить внутрисхемно? Тыкать 100500 точек останова? Или пошагово в течение десятка тысяч тактов проходиться?

итак, тема не раскрыта: в момент остановки исполнения на точке остановки какая периферия продолжает работать в реальном времени?

Добавлено after 30 seconds:
кроме тактового генератора, естественно

Открывай мануал на свой ARM и читай, какую периферию производитель твоего МК наделил способностью стоять в точке останова. У STM32 почти всё периферию можно тормознуть, а тактироваться она будет только во время работы CPU. Сколько тактов прошло между двумя точками останова, столько тактовых импульсов отработает периферия. Очень удобно, видно даже, как DMA, управляемый такой периферией, складывает в неё данные.

Не владею телепатическими способностями, чтобы угадать про какой МК речь, но например для линейки STM32F4xx следует смотреть в мануале описание регистров: DBGMCU_APB1_FZ, DBGMCU_APB2_FZ.

Для XMC4xxx нужно читать раздел мануала:
и далее...

странно, вроде задаю вопрос по-русски, а ответа не получаю...
все, кто пользуется внутрисхемной отладкой, что, не читали даташит?! почему мне предлагаете его читать? раз пользуетесь, значит, должны знать, значит, можете просто привести примеры в ответ. или я прошу слишком многого?!

Чем внутрисхемная отладка мешает работе периферии, а периферия отладке?

Asmodey, а вот представь: ты поставил breakpoint для отлаживания USB, у тебя моментально сдохла реакция на прерывания USB, host отверг устройство с матюгами, а ты сидишь, и думаешь: что за Ë-моë?

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

Добавлено after 2 minutes 26 seconds:
а вот симулятор - поможет, т.к. при остановке в симуляторе останавливается и "обвязка"

В общем - дело вкуса. Кому - поп, кому - попадья. Закон о единомыслии ещё не ввели.

Что мешает ввести отладочные переменные, в процессе выполнения писать в них все что необходимо контролировать, останавливать и в окне отладки смотреть все после завершения работы с usb? Будет то же самое что с терминалом, только терминал становится лишним и все. Плюс можно оперативно изменить все что угодно, что очень помогает выловить баги. Какие преимущества тут у "односторонней" отладке по uart?

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

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

еще читал книжку по tms320, там отладку драйвера мотора, выполняли при включенных ШИМ. как такие фокусы делаются в stm32 пока не в курсе

..а в отладчике, например, писать в файл, а потом смотреть. Отладка это не только точки останова. Есть ведь и трассировочная макроячейка, через которую можно целые области памяти читать-писать, и даже в виде тренда смотреть вживую если надо.

А зачем его останавливать для отладки? Отладка с остановами используется для проекта на первом этапе. В реальном времени на завершающих стадиях проекта отладчик не останавливают, а просто наблюдают за переменными в Watch, изменяют переменные на лету, а так же смотрят осциллограммы в схеме.

Приводов этих вы не разрабатывали. Соответственно - понять "как поможет" не сможете. Раз даже не поняли как пользоваться ссылками на мануалы - какой смысл ещё объяснять?
Я разрабатывал инверторы для управления двигателями и мне эта отладка помогала при этом. Вам такой ответ как-то помог? Или о чём вообще вопрос?

PS: Если не умеете читать мануалы - для вас все слова будут пустыми. Начните что-то делать реальное, а не теоретизировать впустую - тогда может поймёте пользу от отладчика.

У меня этих железяк уже вагон и маленькая тележка разработано. И как-то вот вообще ни разу даже мысли не было о внутрисхемной отладке. Совершенно бесполезная вещь.
Какой, скажем, смысл в реальном времени играться с регистрами? В RM все четко написано: что, где и куда. Неужто кто-то думает, что если баловаться с битами конфигурации, скажем, SPI, то внезапно откроется какой-нибудь "скрытый в документации" режим?

Эк вам повезло! А ведь надо было, бо без неё - никак
ПыСы Вспомнил: у меня тоже с полдесятка приборов в серию пошла, и как без в.с.о. обошёлся - ума не приложу.

Не обязательно. Никто не мешает остановить выполнение отладчиком в нужный момент. И посмотреть состояние переменных.
Если вдруг выполнение пошло как то "не так" - это очень поможет посмотреть какое состояние переменных/периферии было в этот момент. И выяснить что именно произошло.
А если отладчика нет - придётся писать вывод каких-то переменных в UART (каких именно? если не известно - что пошло не так, а переменных в коде - сотни/тысячи?) А потом ещё пытаться воспроизвести то предыдущее сбойное состояние. А если его воспроизвести не получится? Или очень трудно? Потратили полдня - воспроизвели наконец-то повторно то же состояние. Посмотрели выведенные переменные, оказалось что какой-то нужной переменной не хватает для анализа. Опять всё по-новой - добавляем эту переменную в вывод и тратим ещё полдня на воспроизведение сбойного состояния. И там теряем море времени впустую...
А если бы был отладчик, то нажав буквально пару кнопок: остановив отладчиком и пройдясь по переменным уже через несколько минут находим проблему.

А если воспроизвести сбойное состояние не получается? Что делать?

Добавлено after 3 minutes 23 seconds:
Не всегда так бывает. Скорее даже наоборот - описано процентов 30%. Остальное - "догадайся сам". Поэтому - приходится исследовать и выяснять недосказанное в мануале.
А бывает и просто тупо - ошибки в мануале. И приходится долго исследовать биты/регистры и выяснять правду. И без отладчика такое займёт в разы больше времени. Работал я когда-то и без эмулятора - знаю не понаслышке. Теперь жаль тех бездарно потраченных месяцев, которые не были бы потраченными будь тогда у меня эмулятор....

Чушь какая то. У меня практически все задачи сигнальные. Есть куча мест, где нужно в процессе отладки править коэффициенты, корректировать начальные условия, наблюдать за переменными и еще куча всего.
Кроме этого, имеются (не обязательно в АРМах) модули, с которыми работаешь в первый раз или первый раз используешь какой нибудь функционал. Приходится в начале смотреть отладчиком и по шагам.

Для справки - и какой был МК? И какой размер проекта?

Добавлено after 1 minute 33 seconds:
+++
Вангую, что люди, не понимающие этого, сами никакую периферию не программируют. А пользуются для этого кубо-калами. Потому и не понимают "зачем".