Jump to content

    
Sign in to follow this  
Arlleex

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

Recommended Posts

Доброй ночи.

 

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

В режиме пошаговой отладки прерывания не вызываются НИКОГДА.

В режиме Step Over они вызываются при вызове функции, в которой при записи регистра вызывается прерывание по завершению передачи. Я его ловлю когда делаю Step Over над этой функцией. Ну а если выполнить запись в регистр Single Step-ом, увидеть в NVIC что прерывание ушло в Pending (при этом в периферии тоже видно, что флажок установился на запрос прерывания), то стоит разместить чуть дальше (да хоть на следующей строчке) брэкпоинт, или выполнить до курсора - то прерывание выполняется.

 

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

Share this post


Link to post
Share on other sites
В режиме пошаговой отладки прерывания не вызываются НИКОГДА.

Определите, что такое "не вызываются"? Вообще не исполняется код обработчика прерывания, или отладчик не входит в код обработчика прерывания при пошаге, хотя таковое наверняка щелкает?

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

 

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

 

Share this post


Link to post
Share on other sites
Подтверждаю.

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Если первое - не верю. Даже объяснять не буду, почему.

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

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

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

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

Share this post


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

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

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

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

 

Share this post


Link to post
Share on other sites
" Не верю" касалось варианта, что, якобы, код ISR вообще никак не отрабатывается.

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

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

Share this post


Link to post
Share on other sites
Может и такое быть, точнее ситуация близкая к таковой.

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

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

 

Share this post


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

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

Share this post


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

Если совсем серьёзно, то вроде во всех процессорах, с которыми мне приходилось иметь дело, дело обстоит аналогично: чтение регистров периферии отладчиком аналогично их чтению процессором (либо любым другим bus master-ом). Ну не различает периферия какой именно bus master её читает.

Думаю это потому, что чтение идёт по той же шине, что и другие доступы. А иначе пришлось бы в схему МК внести дополнительную матрицу шин для отладчика, дополнительный арбитр доступа для каждого периферийного узла (чтобы разруливать коллизии с доступом из штатной матрицы шин) и т.д. Это здорово бы (и не обоснованно) усложнило схему МК.

А для чего? Только для отладки? И только чтобы новички реже включали мозг??? не слишком ли высока цена? Может эти ресурсы лучше потратить на какие-то более полезные вещи?

И к тому же это пришлось бы делать для каждого нового МК отдельно (а сейчас отладчик работает только с ядром, входит в его состав и неизменен для любого МК на данном ядре).

И вроде такое поведение (отладчика) должно быть вполне ожидаемым. Хотя почему-то чайники постоянно наступают на эти грабли, хотя вроде казалось бы очевидная вещь.......

Share this post


Link to post
Share on other sites
Думаю это потому, что чтение идёт по той же шине, что и другие доступы. А иначе пришлось бы в схему МК внести дополнительную матрицу шин для отладчика, дополнительный арбитр доступа для каждого периферийного узла (чтобы разруливать коллизии с доступом из штатной матрицы шин) и т.д. Это здорово бы (и не обоснованно) усложнило схему МК.

А для чего? Только для отладки? И только чтобы новички реже включали мозг??? не слишком ли высока цена? Может эти ресурсы лучше потратить на какие-то более полезные вещи?

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

Share this post


Link to post
Share on other sites
Если совсем серьёзно, то вроде во всех процессорах, с которыми мне приходилось иметь дело, дело обстоит аналогично: чтение регистров периферии отладчиком аналогично их чтению процессором (либо любым другим bus master-ом).

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

Думаю это потому, что чтение идёт по той же шине, что и другие доступы. А иначе пришлось бы в схему МК внести дополнительную матрицу шин для отладчика, дополнительный арбитр доступа для каждого периферийного узла (чтобы разруливать коллизии с доступом из штатной матрицы шин) и т.д. Это здорово бы (и не обоснованно) усложнило схему МК.

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

 

Share this post


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

Почему выдумки? Догадка. Логически обоснованная.

Вы в юзермануалах на разные МК видели их блок-схемы? Там где расписаны блоки внутри МК и связи между ними. Так вот на них всегда "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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this