Arlleex 178 24 октября, 2016 Опубликовано 24 октября, 2016 · Жалоба Доброй ночи. Интересует вопрос, почему в Keil uVision Cortex M4 (STM32F4) в режиме отладки по SWD (ST-Link) не заходит в прерывания в пошаговом режиме? Да не только даже в пошаговом. В режиме Step Over тоже, при этом в регистрах NVIC контроллера и в регистрах флагов прерываний самой периферии (SPI) вижу, что прерывание генерируется, в NVIC оно в состоянии Pending, но прерываний больше никаких нет, все разрешены, казалось бы, пожалуйста - бери на себя процессорное время да выполняйся, а нет, не хочет - причем так глюкованно ведет себя, что совсем не понятно. В режиме пошаговой отладки прерывания не вызываются НИКОГДА. В режиме Step Over они вызываются при вызове функции, в которой при записи регистра вызывается прерывание по завершению передачи. Я его ловлю когда делаю Step Over над этой функцией. Ну а если выполнить запись в регистр Single Step-ом, увидеть в NVIC что прерывание ушло в Pending (при этом в периферии тоже видно, что флажок установился на запрос прерывания), то стоит разместить чуть дальше (да хоть на следующей строчке) брэкпоинт, или выполнить до курсора - то прерывание выполняется. С чем связано такое поведение? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 25 октября, 2016 Опубликовано 25 октября, 2016 · Жалоба В режиме пошаговой отладки прерывания не вызываются НИКОГДА. Определите, что такое "не вызываются"? Вообще не исполняется код обработчика прерывания, или отладчик не входит в код обработчика прерывания при пошаге, хотя таковое наверняка щелкает? Если первое - не верю. Даже объяснять не буду, почему. Если второе - то слава провидению и программистам отладчика! Если при пожаговом исполнении попадать в прерывания, то НИКОГДА не получится отладить "синхронный" код, поскольку будете только и делать, что попадать в прерывания. И я на такое наткнулся: использовал какую-то плату Discovery со встроенным, как известно, ST-Link. Так вот (как раскопал и устанил), из-за старой версии драйвера ST-Link и новой прошивки последнего при каждом шаге отладки влетал в какую-нибудь процедуру IRQ. Хотите стать в IRQ - поставьте там точку останова. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 55 25 октября, 2016 Опубликовано 25 октября, 2016 · Жалоба Подтверждаю. При шаговом не заходит, но если надо в IRQ - ставишь BP и заходишь туда. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 26 октября, 2016 Опубликовано 26 октября, 2016 · Жалоба Подтверждаю. При шаговом не заходит, но если надо в IRQ - ставишь BP и заходишь туда. ...что и есть правильно и разумно, а по-простому - ништяк. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 55 26 октября, 2016 Опубликовано 26 октября, 2016 · Жалоба ...что и есть правильно и разумно, а по-простому - ништяк. По-простому - чики-пуки Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
uriy 5 26 октября, 2016 Опубликовано 26 октября, 2016 · Жалоба Несколько проектов делал VisualDSP там есть галочки входить в прерывания или нет при пошаговой отладке. Как тут верно заметили если разрешить вход в прерывания то весь остальной код будет невозможно отладить. Все время будете в прерываниях. В KEIL такой настройки не помню. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 26 октября, 2016 Опубликовано 26 октября, 2016 · Жалоба Если первое - не верю. Даже объяснять не буду, почему. Верьте - не верьте, но в IAR например даже галка такая специальная есть: "Запрет прерываний в пошаговом режиме" (как то так называется). И, если её поставить, именно вызываться ISR не будет. Всегда её ставлю. Но только при "шагании"; при step over функции прерывание может успеть обработаться. Как я понимаю, при каждом шаге, отладчик просто делает временный запрет прерываний. Вероятно подобная галка может быть где-нить и в Keil. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 27 октября, 2016 Опубликовано 27 октября, 2016 · Жалоба Верьте - не верьте, но в IAR например даже галка такая специальная есть: "Запрет прерываний в пошаговом режиме" (как то так называется). Вероятно подобная галка может быть где-нить и в Keil. Галки такой в KEIL не наблюдал. По поводу "не верю". Из текста ТС было не ясно, что именно в ISR происходит. " Не верю" касалось варианта, что, якобы, код ISR вообще никак не отрабатывается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Edit2007 3 28 октября, 2016 Опубликовано 28 октября, 2016 · Жалоба " Не верю" касалось варианта, что, якобы, код ISR вообще никак не отрабатывается. Может и такое быть, точнее ситуация близкая к таковой. Если в окно WATCH вытащить регистры перефирии, тогда возможна ситуация, при которой отладчик считывает содержимое регистра для обновления в окошке, при чтении регистра (ему ведь все равно кто считал) сбрасываются флаги прерывания и соответственно прерывание даже если и вызывается, то не находит флагов и "не отрабатывает" нужный кусок кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 29 октября, 2016 Опубликовано 29 октября, 2016 · Жалоба Может и такое быть, точнее ситуация близкая к таковой. Если в окно WATCH вытащить регистры перефирии, тогда возможна ситуация, при которой отладчик считывает содержимое регистра для обновления в окошке, при чтении регистра (ему ведь все равно кто считал) сбрасываются флаги прерывания и соответственно прерывание даже если и вызывается, то не находит флагов и "не отрабатывает" нужный кусок кода. Вообще говоря, такое теоретически недопустимо, поскольку отладчик обязан быть nonintrusive, то есть, он никак не влияет на поведение устройства. Практика показывает, однако, что именно ST страдают (начиная с F1xx) некоторыми поведенческими особенностями при отладке. В частности, SPI и I2C. Я лично сталкивался с подобными "непонятками", которые исчезали при закрытии окон, подсматривающих за периферийными регистрами. Об этом упоминается (и мною) неоднократно на просторах форума STM32. Я говорю о "непонятках", т.к. у меня не было ни времени, ни желания доказывать ST, что они, возможно, накосячили, и настоящего исследования с доказательствами у меня нет. У меня закралось подозрение, что внутри STM32 сидит квантовый процессор, состояния которого разрушаются при подглядывании ;) . Если серьёзно, то сброса флагов прерывания быть не должно, а если набредете на устойчивое проявление такого поведения, поделитесь постановкой эксперимента. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 29 октября, 2016 Опубликовано 29 октября, 2016 · Жалоба Практика показывает, однако, что именно ST страдают (начиная с F1xx) некоторыми поведенческими особенностями при отладке. В частности, SPI и I2C. Я лично сталкивался с подобными "непонятками", которые исчезали при закрытии окон, подсматривающих за периферийными регистрами. Это не секрет. По крайней мере, про I2C в мануале английским по белому написано, как чтение регистра статуса меняет состояние периферии в некоторых ситуациях, то есть отладчик легко может нарушить последовательность обмена по I2C. Какому гению пришла в голову светлая мысль сделать такое - остаётся только догадываться. Вообще у них I2C пришибленный и в других местах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 29 октября, 2016 Опубликовано 29 октября, 2016 · Жалоба Если серьёзно, то сброса флагов прерывания быть не должно, а если набредете на устойчивое проявление такого поведения, поделитесь постановкой эксперимента. Если совсем серьёзно, то вроде во всех процессорах, с которыми мне приходилось иметь дело, дело обстоит аналогично: чтение регистров периферии отладчиком аналогично их чтению процессором (либо любым другим bus master-ом). Ну не различает периферия какой именно bus master её читает. Думаю это потому, что чтение идёт по той же шине, что и другие доступы. А иначе пришлось бы в схему МК внести дополнительную матрицу шин для отладчика, дополнительный арбитр доступа для каждого периферийного узла (чтобы разруливать коллизии с доступом из штатной матрицы шин) и т.д. Это здорово бы (и не обоснованно) усложнило схему МК. А для чего? Только для отладки? И только чтобы новички реже включали мозг??? не слишком ли высока цена? Может эти ресурсы лучше потратить на какие-то более полезные вещи? И к тому же это пришлось бы делать для каждого нового МК отдельно (а сейчас отладчик работает только с ядром, входит в его состав и неизменен для любого МК на данном ядре). И вроде такое поведение (отладчика) должно быть вполне ожидаемым. Хотя почему-то чайники постоянно наступают на эти грабли, хотя вроде казалось бы очевидная вещь....... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 29 октября, 2016 Опубликовано 29 октября, 2016 · Жалоба Думаю это потому, что чтение идёт по той же шине, что и другие доступы. А иначе пришлось бы в схему МК внести дополнительную матрицу шин для отладчика, дополнительный арбитр доступа для каждого периферийного узла (чтобы разруливать коллизии с доступом из штатной матрицы шин) и т.д. Это здорово бы (и не обоснованно) усложнило схему МК. А для чего? Только для отладки? И только чтобы новички реже включали мозг??? не слишком ли высока цена? Может эти ресурсы лучше потратить на какие-то более полезные вещи? Выдумки. Просто не нужно было делать так, что чтение регистра меняет состояние периферии. Списывать это новичков - левая отмазка. Проектировщикам МК тоже надо межушный ганглий иногда активировать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KnightIgor 2 29 октября, 2016 Опубликовано 29 октября, 2016 · Жалоба Если совсем серьёзно, то вроде во всех процессорах, с которыми мне приходилось иметь дело, дело обстоит аналогично: чтение регистров периферии отладчиком аналогично их чтению процессором (либо любым другим bus master-ом). Это печально. Думаю это потому, что чтение идёт по той же шине, что и другие доступы. А иначе пришлось бы в схему МК внести дополнительную матрицу шин для отладчика, дополнительный арбитр доступа для каждого периферийного узла (чтобы разруливать коллизии с доступом из штатной матрицы шин) и т.д. Это здорово бы (и не обоснованно) усложнило схему МК. JTAG определяет обязанность обеспечить nonintrusive режим. Для этого организуется совершенно независимый канал команд и данных, который "подключен" непосредственно к тем триггерам, которые и являют собой те или иные регистры ядра и периферии. По-видимому, с целью экономии производители действительно мухлюют. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 30 октября, 2016 Опубликовано 30 октября, 2016 · Жалоба Выдумки. Просто не нужно было делать так, что чтение регистра меняет состояние периферии. Списывать это новичков - левая отмазка. Проектировщикам МК тоже надо межушный ганглий иногда активировать. Почему выдумки? Догадка. Логически обоснованная. Вы в юзермануалах на разные МК видели их блок-схемы? Там где расписаны блоки внутри МК и связи между ними. Так вот на них всегда "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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться