Доброй ночи.

Интересует вопрос, почему в Keil uVision Cortex M4 (STM32F4) в режиме отладки по SWD (ST-Link) не заходит в прерывания в пошаговом режиме? Да не только даже в пошаговом. В режиме Step Over тоже, при этом в регистрах NVIC контроллера и в регистрах флагов прерываний самой периферии (SPI) вижу, что прерывание генерируется, в NVIC оно в состоянии Pending, но прерываний больше никаких нет, все разрешены, казалось бы, пожалуйста - бери на себя процессорное время да выполняйся, а нет, не хочет - причем так глюкованно ведет себя, что совсем не понятно.
В режиме пошаговой отладки прерывания не вызываются НИКОГДА.
В режиме Step Over они вызываются при вызове функции, в которой при записи регистра вызывается прерывание по завершению передачи. Я его ловлю когда делаю Step Over над этой функцией. Ну а если выполнить запись в регистр Single Step-ом, увидеть в NVIC что прерывание ушло в Pending (при этом в периферии тоже видно, что флажок установился на запрос прерывания), то стоит разместить чуть дальше (да хоть на следующей строчке) брэкпоинт, или выполнить до курсора - то прерывание выполняется.

С чем связано такое поведение?

Определите, что такое "не вызываются"? Вообще не исполняется код обработчика прерывания, или отладчик не входит в код обработчика прерывания при пошаге, хотя таковое наверняка щелкает?
Если первое - не верю. Даже объяснять не буду, почему. Если второе - то слава провидению и программистам отладчика! Если при пожаговом исполнении попадать в прерывания, то НИКОГДА не получится отладить "синхронный" код, поскольку будете только и делать, что попадать в прерывания. И я на такое наткнулся: использовал какую-то плату Discovery со встроенным, как известно, ST-Link. Так вот (как раскопал и устанил), из-за старой версии драйвера ST-Link и новой прошивки последнего при каждом шаге отладки влетал в какую-нибудь процедуру IRQ.

Хотите стать в IRQ - поставьте там точку останова.

Подтверждаю.
При шаговом не заходит, но если надо в IRQ - ставишь BP и заходишь туда.

...что и есть правильно и разумно, а по-простому - ништяк.

По-простому - чики-пуки

Несколько проектов делал VisualDSP там есть галочки входить в прерывания или нет при пошаговой отладке. Как тут верно заметили если разрешить вход в прерывания то весь остальной код будет невозможно отладить. Все время будете в прерываниях.
В KEIL такой настройки не помню.

Верьте - не верьте, но в IAR например даже галка такая специальная есть: "Запрет прерываний в пошаговом режиме" (как то так называется). И, если её поставить, именно вызываться ISR не будет. Всегда её ставлю.
Но только при "шагании"; при step over функции прерывание может успеть обработаться.
Как я понимаю, при каждом шаге, отладчик просто делает временный запрет прерываний.
Вероятно подобная галка может быть где-нить и в Keil.

Галки такой в KEIL не наблюдал.
По поводу "не верю". Из текста ТС было не ясно, что именно в ISR происходит. " Не верю" касалось варианта, что, якобы, код ISR вообще никак не отрабатывается.

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

Вообще говоря, такое теоретически недопустимо, поскольку отладчик обязан быть nonintrusive, то есть, он никак не влияет на поведение устройства. Практика показывает, однако, что именно ST страдают (начиная с F1xx) некоторыми поведенческими особенностями при отладке. В частности, SPI и I2C. Я лично сталкивался с подобными "непонятками", которые исчезали при закрытии окон, подсматривающих за периферийными регистрами. Об этом упоминается (и мною) неоднократно на просторах форума STM32. Я говорю о "непонятках", т.к. у меня не было ни времени, ни желания доказывать ST, что они, возможно, накосячили, и настоящего исследования с доказательствами у меня нет. У меня закралось подозрение, что внутри STM32 сидит квантовый процессор, состояния которого разрушаются при подглядывании . Если серьёзно, то сброса флагов прерывания быть не должно, а если набредете на устойчивое проявление такого поведения, поделитесь постановкой эксперимента.

Это не секрет. По крайней мере, про I2C в мануале английским по белому написано, как чтение регистра статуса меняет состояние периферии в некоторых ситуациях, то есть отладчик легко может нарушить последовательность обмена по I2C. Какому гению пришла в голову светлая мысль сделать такое - остаётся только догадываться. Вообще у них I2C пришибленный и в других местах.

Если совсем серьёзно, то вроде во всех процессорах, с которыми мне приходилось иметь дело, дело обстоит аналогично: чтение регистров периферии отладчиком аналогично их чтению процессором (либо любым другим bus master-ом). Ну не различает периферия какой именно bus master её читает.
Думаю это потому, что чтение идёт по той же шине, что и другие доступы. А иначе пришлось бы в схему МК внести дополнительную матрицу шин для отладчика, дополнительный арбитр доступа для каждого периферийного узла (чтобы разруливать коллизии с доступом из штатной матрицы шин) и т.д. Это здорово бы (и не обоснованно) усложнило схему МК.
А для чего? Только для отладки? И только чтобы новички реже включали мозг??? не слишком ли высока цена? Может эти ресурсы лучше потратить на какие-то более полезные вещи?
И к тому же это пришлось бы делать для каждого нового МК отдельно (а сейчас отладчик работает только с ядром, входит в его состав и неизменен для любого МК на данном ядре).
И вроде такое поведение (отладчика) должно быть вполне ожидаемым. Хотя почему-то чайники постоянно наступают на эти грабли, хотя вроде казалось бы очевидная вещь.......

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

Это печально.

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

Почему выдумки? Догадка. Логически обоснованная.
Вы в юзермануалах на разные МК видели их блок-схемы? Там где расписаны блоки внутри МК и связи между ними. Так вот на них всегда "Test/Debug interface" входит в состав (или подключен к) только ядра Cortex-M. Из которого уже выходит несколько шин (I-code, D-code, System) подключенных к матрице шин AHB, к которой подключены также и другие bus master-ы, память, а также периферия через мосты AHB-APB. Часто причём эти APB-блоки работают на другой частоте нежели AHB. И доступ например CPU к периферии идёт через AHB->APB с арбитражём между ним и другими bus master и синхронизацией для согласования частот.
И никаких отдельных путей/связей от блока отладчика JTAG/SWD я ни на одной блок-схеме не видел. Как же тогда этот самый отладчик сможет обратиться к периферии??? Да ещё при этом избежать конфликтов с доступами от других bus master? Да ещё выполнить синхронизацию (ведь целевой блок APB может работать на другой частоте нежели CPU)?
Или Вы думаете содержимое этих регистров периферии к Вам в отладчик телепортируется само собой?
Нет, должны быть пути. И я вижу только один путь - штатный доступ как CPU. Конечно в наборе сигналов управления шины может быть какой-то сигнал говорящий периферии что это доступ не ядра, а отладчика, но очевидно что его нет.
Да и вообще я не вижу особой необходимости в этом. Просто надо всегда понимать что ты делаешь и как, и как это будет работать внутри МК.


Это упрощение. И, по-моему, вполне обоснованное. Из моей практики - не помню когда у меня возникали затруднения с таким способом работы отладчика.
А для чтения регистров, чувствительных к чтению, в каких-то МК я видел другой механизм: кроме собственно регистра с такими флагами, есть ещё один регистр с точно такими же флагами, но чтение его не приводит к их изменению. И в комментарии подписано, что этот регистр введён именно в целях отладки. Такой способ имхо реализовать гораздо проще, чем наворачивать отдельную кухню для чтения периферии отладчиком мимо CPU.