Место надо найти сначала . А ошибки и без прогона глазом в исходнике видно, если место известно хоть с каой-то точностью. Самое главное в локализации общесистемных и реалтаймовых ошибок внутрисхемный отладчик крайне мало полезен.

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

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

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

Я сказал ошибка видна "сразу" - это, конечно, условно. Нужны итерации, но довольно тупые, объясняю на примерах:
1. Программа не дошла до места. Здесь просто тупо ставим точки останова перед тем местом и с каждой итерацией точки удаляем и находим ту процедуру где застревает. Итерации заключается просто в переустановке точки останова и рестарте, все очень быстро и механически.
2. Программа в аборте. Здесь просто смотрим LR регистр, и все остальные регистры. Смотрим че там по адресу из LR находится. По MAP файлу узнаем имя процедуры и разбираемся, но конкретно уже без домыслов.
3. Программа гуляет черт знает где и не живая. Здесь делаем останов и смотрим че стало с RAM-ом. Часто уже там сплош мусор. Тогда находим с какого места он начал расти и ставим точку останова по записи в тот адрес. На следующем рестарте мы узнаем кто туда пишет мусор.

Ни и т.д. , можно продолжать перечислять сценарии где простой терминал ничем не поможет.

Насчет макросов.
Я не против всех макросов. А только против макросов условной компиляции и в частности отладочных.
Дело в том, что SlickEdit плохо ориентируется при поиске объявлений и реализаций тех или иных объектов если они были скрыты или переименованы макросами. Также ненадежно работает рефактроинг. Когда в тексте встречаются макросы условной компиляции приходится перенапрягать память чтобы вспомнить какие блоки активны.
Изучать чужие тексты переполненные макросами просто кошмар.

И еще, 90% текстов в серьезных прогах - чужие. Еще 9% это библиотеки компилятора к которым вообще нет исходников. Так, что реально "анализировать" алгоритмы не приходится, они либо верны, либо мы меняем компилятор и не связываемся с сомнительным софтом.
Ошибки с которыми в основном приходится бороться это ошибки сбоев периферии и вызванные багами кристаллов, ошибки неинициализированных указателей, ошибки парсинга компиляторов, ошибки или недопонимание ретаргетинга компиляторов на целевую платформу, т.е. чисто технические непредсказуемые и слабо зависящие от программиста ошибки, терминал здесь явно неэффективен.

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

Подход к делу ясен У меня крайне мало чужих, которых я не пропустил через себя, которые не стали "моими" и в которых я не достаточно уверенно орентируюсь.

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

Аналогично, только LR и все прочее мне выдает отладочная консолька в загрузчике. Причем выдает всегда и везде а не только когда я (а не кто-то на объекте) работаю в комфортных условиях с подключеным отладчиком. Ну и на ARM платформе я не вылетал ни разу еще , если не считать специально при проверке работоспособности.

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

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

Это примиряет

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

У меня тоже не грузилось во FLASH на AT91SAM7S256
Мне на этом форуме подсказали решение Options->Debugger->Download->Edit и должны получить след. строчку ,,,0x00100000,(default),
т.е. Reallocate Base Address установить крыж и значение 0x00100000

Несмотря на то, что все ругают Wiggler, у меня он работает стабильно, через RDI с последней версией H-JTAG в IAR и в KEIL.

Сейчас купил MT-LINK и тоже доволен.

пока только 2 дня изучаю ARM , мучаю 91SAM7S64. есть IAR+Wigler, согласен что отладка это дело любителя, на AVR никогда таким не пользовался, а все изза того что был нормальный low-cost программатор и avreal или ponyprog компилил шил и сразу смотрел результат. А здесь непонятно както, есть SAM-BA но все время тыкать джампер и кабель USB дергать так далеко не уедеш по моему, вот и занялся вотросом программирования через J-TAG. Кто как выходит из этого положения??? H-JTAG пробывал, пока не понятно, чтото онругается. Пока единственный вариант это заливка во флеш из IAR. но как я понял для нормальной работы необходимы нормально-сконфигурированные .xcl и .mac файлы проекта... пока получилось токлько залить примерчик Atmel со светодиодом, а вот свой проект со светодиодом уже не пошел, т.к. нет нормального сконфирурированного проекта. Еще попутный вопрос, вроде облазил весь форум,ничего не нашел, по поводу конфигурирования .xcl и .mac, есть ли линки по этому поводу???

А зачем форум, если смотреть нужно в документации на линкер Help->Linker Tools.... Там все более, чем подробно.
По *.mac - аналогично, но думаю, что менять пока Вам вообще нечего относительно имеющегося по умолчанию.