наверное, не знают про отладчик...

Наверное не знают про наверное....

Я проверяю свои проекты в симуляторе AVR-Studio. Притом, только программную и логическую часть. Если требуется, делаю тестовые куски кода. Если в проекте дисплей, вывожу тестовую информацию на дисплей. Если дисплея нет и ног хватает, подключаю дисплей. Если малоногий МК, вывожу тестовую информацию на светодиод. Комбинация коротких и долгих вспышек. Единицы короткие. Десятки длинные. Либо. До 5 короткие, 5 более долгая вспышка, десятки долгие вспышки.

И я аналогичным образом примерно делаю. Одного пина достаточно для отладки через COM-порт. Есть экран - задействуем экран. Когда понадобилась 3-х байтовая математика, отладил в симуляторе. Не вижу преимуществ реального кристалла супротив симулятора, например при отладке умножения/деления.

Я также говорил себе, что хватит. Так было ... до начала занятий с STM32 . Теперь ищу debug и в других МК. Где есть, где нет ...

Для отладки ассемблерного кода в рамках ядра вполне достаточно отладки, заложенной в авр студио.
Другое дело, когда помимо ядра в состав МК включаются дополнительные аппаратные модули (речь о "встроенных", а не о "внешних"!!).
Это уже не просто отладчик, а частично симулятор для тех аппаратных модулей добавляется.
В подобных случаях и аппаратный дебаггер не всегда справиться может - надо вспоминать те методы, что в "древние времена" при отладке конструкций с СБИС периферии применяли - когда порты ввода/вывода, таймеры , память и прочее "снаружи" от МК были.
АВРки в основном имеют стабильный минимальный набор хорошо отработанной периферии.
Отладка в рамках ядра вполне предсказуема. Возможно чего то нового со временем будет добавляться - но то уже не вопрос применения и отладки ассемблерного кода, а вопрос работы с расширенной аппаратной начинкой периферийных блоков (т.е. не данной темы).

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

Это вариант именно работы с аппаратными модулями "за пределами ядра".
Там от реакции / взаимодействия с аппаратной частью много зависимостей.
Но к самой системе команд и работе ядра подобная ситуация не относится - найдите хоть одно семейство МК, где система команд и базовое ядро имеют ошибки...
Или команды ассемблера могут как-то иначе, чем в документации описано, выполняться.
А вот относительно аппаратной периферии - раздолье по ерратам...

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

Отладка ядра возникает при работе с данными, которые поступают снаружи. Проблема именно в этом.
Вы не можете симулировать эти данные. Они в общем виде случайны, а часто зависят от выходных состояний МК.
Поэтому нужна реальная работа.
Особенно в АСМе.

Как раз поток данных можно симулировать, а вот поведение аппаратной части периферии - нет.
(Или достаточно сложно - потребуется добавлять в IDE корректно спроектированный симулятор).
К примеру момент включения прерываний, переполнения счетчиков при разнохитрых комбинациях их аппаратных (программно независимых/программно недоступных) схем управления и прочего именно аппаратного состава встроенной периферии.
Посему и возникает потребность во всякодебаггерах.
Ежли бы там только программная начинка работала - то и возможное состояние было бы вполне предсказуемым.

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

Вполне предсказуем по значению (относительно программного кода и данных), НО положение (момент возникновения) в случае работы с прерываниями может вызвать дополнительные вопросы, требующие анализа как на приоритет прерываний, так и на возможные критические "накладки" при их возникновении.

Дальше работает как надо и всё. Работа с периферией и внешними воздействиями отлажена другими методами. Контроллер прошит, работает.

Отладка элементарных вещей симулятором нужна лишь на самом начальном этапе изучения.
Поэтому говорить о ней как о серьезном инструменте неуместно. Есть симулятор - и хорошо. Пару раз за проект может потребуется. Да и то не всегда. Быстрее в железном дебаге посмотреть.
Какой смысл иметь несколько инструментов, когда все можно сделать одним?

Многие уже и не обращают внимания на "некоторые тонкости" архитектуры современных МП/МК...
А надо бы о том помнить (особо при отладке сложных ситуаций)...
К примеру вместо многофазной синхронизации процессов извлечения и исполнения команд (использовался в "МК на рассыпухе" и там где "много тактов на команду" - та же "классика" mcs51, I8080) применяется "статика" с одним тактом...
Добавим работу того же конвеера предвыборки команд (без коего со времен ПИКовых практически ни одно современное семейство не обходится)...
Вот и повод для интенсивного внедрения аппаратной отладки вида "дебаггер на кристалле".

Сколько сейчас стоит нормальный дебаггер для AVR?

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

Как уже было выше сказано, дебаггер должен поддерживаться средой разработки.
Я работаю с ATmega165 в MPLABX и использую в качестве дебаггера PICkit4.
Поскольку дебаг в AVR происходит через JTAG, то полагаю, что есть варианты и для использования J-link.
J-link (не родной, естественно) стоит очень дешево.

Почему нечего смотреть в симуляторе?
МК не только взаимодействует с внешней аппаратурой, он ещё производит расчёты.
У симулятора своя ниша, в которой он успешно используется, например, расчёт какой-либо функции.
Надо проверить правильность расчёта и точность во всём диапазоне аргумента, это много точек, в симуляторе это сделать очень удобно.
Причём можно сделать без самого устройства, т.е. отлаживать на компьютере, на котором пишется программа, а это чистое просторное место.
А при реальной отладка на радиомонтажном столе работать с компьютером не очень удобно, поскольку стол занят приборами, паяльной станцией, инструментами и т.д.
Ошибку при записи во флеш в вашей задаче, скорее всего, можно было бы легко обнаружить в хорошем симуляторе.


При чём тут экономия? Вы пока не показали, в чём преимущество вашего штатного аппаратного дебаггера по сравнению с моим. Вообще, как на нём проводится отладка в реальном времени?
Спрашивал у Just_Fluffy, у неё при отладке производится остановка МК, это сильно ограничивает применение.
Отладка с помощью подмигивающих светодиодов, подключаемых дисплеев, СОМ-порта и т.д. – это что-то школьно-любительское для начинающих.