Прежде чем пойти и тихо удавиться решил попросить совета здесь.

В результате ряда манипуляций с программой, отлаживаемой в IAR ARM v.4.11a
с помощью J-Link из IAR-KIT добился следующего:

В отладчике не работают никакие прерывания, хотя все служебные регистры
читаются как надо.
Вне отладчика - все работает как надо.

Еще несколько часов назад и в отладчике все было отлично. Что случилось, понять
не могу, уже близок к суициду

Буду рад любым соображениям по теме...

Бывает не работает часть прерываний, бывает все. Бился (и инициализация, и сбросы, и со скриптами перед запуском отладчика колдовал) долго и безнадежно.
Помогла только 5 версия железа J-Link, точнее поддержка этим железом опции
"adaptive clocking". Все взяло и заработало. Эффект несколько ослабевал при использовании
segger-овских DDLок посвежее - посетите segger.com.

Все страньше и страньше..

Воспользовался Вашим советом, обновил драйвер с СЕГГЕРа. Легче не стало.

НО! Пару месяцев назад я угробил несколько дней, пытаясь заставить работать
RDI. Так и не смог. А тут ткнулся по старой памяти и все пошло влегкую -
молниеносная загрузка и куча точек останова.

Естественно, в RDI появилась опция Adaptive clocking, только с ней все очень
медленно (у меня JLink 3-ей версии). Но прерывания все равно не работают в
отладчике.

А в V3 в принципе нет (мне так кажется) поддержки Adaptive clocking. Что-то как-то выставляет и как-то в принципе работает, но на эффекте прерываний не сказывается. Про V5 я писал, поскольку у меня есть старый эквивалент и новый полный клоны J-Link V5. На V5 однозначно рабочая опция и железно помогает c глюком.
Кстати, у меня эффект с пропаданием проявляется 100% при 'штатном' обязательном останове на 0 адресе. При переносе его на main() еще меньше и так далее... Cо свежими драйверами спокойно преносит железный сброс и можно после зависания прерываний reset -> break -> установить brekpoint -> run и все работает.
И еще, у меня эффект был завязан на процесс прошивки Flash, поэтому, если прошить а потом отключить загрузку и только отладка, то тоже без потерь прерываний. Неудобно, конечно, лазить в опции, но помогает.

Было подобное. То генрятся то нет.
Соображения такие: при сбросе отладчиком происходит только сброс ядра, но не контроллера прерываний. Если перед этим обрабатывалось какое-то прерывание и логика контроллера не была сброшена (VICVecAddr = 0 или AIC_EOICR = 0) то следующее прерывание не генерится.
Поборол принудительным сбросом контроллера прерываний в процедуре инициализации.

У меня МТлинк и даже не 5 версии. Работаю через RDI последней версии. Как заполучил отладчик - начал ставить разные версии драйверов, ковыряться в настройках. В результате на каком-то этапе вообще перестало работать, хотя командер видел. Чего я только не делал, чтоб реанимировать. Помогла только переустановка оси. Сейчас все настройки поумолчанию. Правда через некоторое время плохо стало соединяться. Тогда в начтройках CPU поставил задержку на 200 млс и пока все стабильно. Прада если надо брэкпоинт поставить, сначала надо по шагам немного пройтись, поставить брэкпоинт и только после этого запускать.

Огромное спасибо всем за участие.

Дело кончилось тем, что я скачал и поставил EWA версии 4.40а в
дополнение к новым драйверам от segger.

Все заработало как часы, вопрос в том, надолго ли.
Причем в JLink-е теперь неограниченное количество точек останова,
но RDI по прежнему грузит раза в 3 быстрее.

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

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

Если поставить точку останова в прерывании, а затем сделать сброс,
прерывания перестают работать.

Поставил в стартапе EOICR = 0 и эта проблема исчезла, так что совет очень дельный.

Может не совсем правильно выразился, вот sgrig понял. Под сбросом я понимал вот что: Почему-то мне запомнилась фраза "This will reset VIC logic", хотя сейчас в мануале ее не нашел, видимо сам ассоциативно выдумал ;-). Для AT91 аналогичное происходит при записи в EOICR.

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

Попробовал. Как и следовало ожидать, строка
"Write32( 0xFFFFF030, 0x00000000 );"
в скрипте эффекта не оказала, зато выяснилось, что все нормально работает
не только при 'Adaptive clocking', но и при зажатии JTAG на фиксированной скорости 2000KHz и более.
На меньших скоростях - нестабильнось. На скоростях мене 1000KHz - полная неработоспособность.
В штатной (не RDI) поддержке есть опция Auto, но с начальной скоростью, так вот, указание более высокой начальной скорости ничего не меняет.