Перейти к содержанию
    

Прерывания в пошаговом режиме Keil

Доброй ночи.

 

Интересует вопрос, почему в 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 и заходишь туда.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Подтверждаю.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

В KEIL такой настройки не помню.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если первое - не верю. Даже объяснять не буду, почему.

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

Но только при "шагании"; при step over функции прерывание может успеть обработаться.

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

Вероятно подобная галка может быть где-нить и в Keil.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Верьте - не верьте, но в IAR например даже галка такая специальная есть: "Запрет прерываний в пошаговом режиме" (как то так называется).

Вероятно подобная галка может быть где-нить и в Keil.

Галки такой в KEIL не наблюдал.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

" Не верю" касалось варианта, что, якобы, код ISR вообще никак не отрабатывается.

Может и такое быть, точнее ситуация близкая к таковой.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может и такое быть, точнее ситуация близкая к таковой.

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Практика показывает, однако, что именно ST страдают (начиная с F1xx) некоторыми поведенческими особенностями при отладке. В частности, SPI и I2C. Я лично сталкивался с подобными "непонятками", которые исчезали при закрытии окон, подсматривающих за периферийными регистрами.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Если совсем серьёзно, то вроде во всех процессорах, с которыми мне приходилось иметь дело, дело обстоит аналогично: чтение регистров периферии отладчиком аналогично их чтению процессором (либо любым другим bus master-ом). Ну не различает периферия какой именно 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. Конечно в наборе сигналов управления шины может быть какой-то сигнал говорящий периферии что это доступ не ядра, а отладчика, но очевидно что его нет.

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

 

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

Это упрощение. И, по-моему, вполне обоснованное. Из моей практики - не помню когда у меня возникали затруднения с таким способом работы отладчика.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...