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

Запрет остановки / паузы отладки

Отлаживаю дивайс на STM32 с помощью JLink. Иногда требуется "запаузить" отладку, посмотреть состояние переменных и т.п. Если момент паузы приходится когда на силовую часть подано напряжение (с ЦАПа), резисторы начинают гореть. Есть ли возможность запретить остановку прогаммы JLink-ом на каком то интервале программного кода?

Изменено пользователем nanorobot

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


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

Навряд ли. Но можно наставить точки останова в безопасные места и включать/отключать их всех сразу на всем скаку иконкой "Skip all breakpoints (Ctrl+Alt+B )"

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


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

Навряд ли. Но можно наставить точки останова в безопасные места и включать/отключать их всех сразу на всем скаку иконкой "Skip all breakpoints (Ctrl+Alt+B )"

 

 

Переключение "Skip all breakpoints" У меня вызывет какие то неясные сбои в выполнении программы. Не каждый раз, но достаточно часто.

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


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

Есть ли возможность запретить остановку прогаммы JLink-ом на каком то интервале программного кода?

Например IAR позволяет написать макросы execUserExecutionStarted() и execUserExecutionStopped(), которые он будет вызывать при старте и остановке выполнения кода.

А в них можно сделать переключение каких-то пинов на безопасные значения - при стопе и восстановление их значений - при старте.

Может и Ваш компилятор это умеет. Смотреть поддержку C-SPY.

Насчёт запрета остановки - не знаю - читайте раздел мануала на свой МК, описывающий отладочный интерфейс (у STM32 называется DBG).

 

Переключение "Skip all breakpoints" У меня вызывет какие то неясные сбои в выполнении программы. Не каждый раз, но достаточно часто.

При таких операциях с бряками происходит пауза выполнения кода. Вероятно что-то у Вас критично к этому.

Например - какая-то периферия при останове отладчиком у Вас продолжает работать, а программа не рассчитана на это.

Тактирование многой периферии можно отключать при останове МК. Для этого есть соответствующие биты в DBG.

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


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

Есть ли возможность запретить остановку прогаммы JLink-ом на каком то интервале программного кода?

 

Классический интерфейс SW отладки всегда останавливает программу для обновления переменных в отладчике. Есть вариант использовать трассировку через интерфейс jtag. В этом случае можно не останавливать программу, но количество переменных для одновременного просмотра будет ограничено, точнее количество участков памяти - блок памяти можно скидывать целиком.

Есть ещё вариант использования SWO - однонаправленная связь, чисто для лога.

И ещё вариант использования RTT технологии от https://www.segger.com/systemview.html?p=1731, и EBmonitor от https://www.embitz.org/forum/thread-647.html. Это клоны. Двухсторонняя связь без остановки программы через SW.

 

Более дешёвый и быстрый вариант - банальный usart. Для него придётся писать собственный обработчик событий. А так-же желательно использование оптической развязки. В этом варианте подобный интерфейс может использоваться даже на установленном оборудовании, чего лишены все остальные варианты.

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


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

А у ARM же есть режим отладки monitor mode

вроде j-link поддерживает

https://www.segger.com/monitor-mode-debugging.html

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


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

Отлаживаю дивайс на STM32 с помощью JLink. Иногда требуется "запаузить" отладку, посмотреть состояние переменных и т.п. Если момент паузы приходится когда на силовую часть подано напряжение (с ЦАПа), резисторы начинают гореть. Есть ли возможность запретить остановку прогаммы JLink-ом на каком то интервале программного кода?

Можно включить watchdog, который быстро перезагрузит процессор при неожиданной остановке. А в тех местах, где остановка разрешена, можно устанавливать бит блокировки watchdoga при входе в отладчик.

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


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

Иногда требуется "запаузить" отладку, посмотреть состояние переменных и т.п. Если момент паузы приходится когда на силовую часть подано напряжение (с ЦАПа), резисторы начинают гореть.

Позволю себе немного по-умничать: © "Поздно пить боржоми, когда ..." ;)

Cамый надежный способ - аппаратный!

Схема не должна ничего жечь, если проц не прошит, прошит кривой прошивкой (где-то в коде завис) или находится в принудительном сбросе.

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

Железобетонное и очень простое решение!

Более сложные ситуации требуют применения внешних "сторожевых систем", которые должны своевременно "кормиться" процом.

Это полезно на случай, если проц уже успел проинициализировать порты, но где-то вдруг завис.

 

Но все нужно учитывать заранее - еще на этапе проектирования принципиальной схемы B)

 

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

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

Если "сила" самодельная, то это нужно предусматривать в обязательном порядке - вход разрешения "силы" должен быть предусмотрен в любом нормальном силовом девайсе!

 

Более того это очень полезно при смене прошивки через JTAG (SWD), т. к. в процессе прошивки все порты "висят" в воздухе.

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


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

Более того это очень полезно при смене прошивки через JTAG (SWD), т. к. в процессе прошивки все порты "висят" в воздухе.

Вашу мысль про устойчивость на аппаратном уровне поддерживаю, но чего это они все "в воздухе висят" во время программирования? Разве что инструмент программирования очень простой. В том же OpenOCD можно проинициализировать что угодно, и как надо (я, например, LTDC запускаю, чтобы матрицу не мучать во время программирования - показывает синенький экран :)).

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


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

но чего это они все "в воздухе висят" во время программирования?

Насколько мне известно, в процессе прошивки тактирование cpu и всей периферии отключается.

Поэтому, если пин никуда не притянут снаружи, на нем может быть что угодно!

А что именно - уже зависит от опыта схемотехника ;)

 

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

 

я, например, LTDC запускаю, чтобы матрицу не мучать во время программирования - показывает синенький экран

А я просто притянул вход RST к нулю внешним резистором, и вход контроллера питания подсветки тоже притянул в состояние, соотв. отключению.

Т.е. при прошивке экран просто полностью гаснет )))

Ну и после подачи питания только что спаянного устройства (камень прошивается внутрисхемно) экран черный.

 

По теме:

 

я не внимательно прочитал вопрос ТС, поэтому поправлюсь:

поможет использование передачи выбранных переменных по USART или мой любимый способ - Segger SystemViewer (очень удобно, если используется rtos).

Впрочем, это тут уже прозвучало :rolleyes:

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


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

Насколько мне известно, в процессе прошивки тактирование cpu и всей периферии отключается.

Не знаю как в других, но OpenOCD шьет флеш-память с помощью маленькой вспомогательной программы в ОЗУ (другие думаю так же делают). Так что все работает, более того можно в скриптах включить PLL и получить приличное ускорение верификации программы.

 

Для банальной смены прошивки не вижу смысла использовать сложные инструменты.

Проще OpenOCD наверное некуда.

 

А я просто притянул вход RST к нулю внешним резистором, и вход контроллера питания подсветки тоже притянул в состояние, соотв. отключению.

Подсветка не при делах - она ничего не портит (ну кроме разве что внешнего вида). А вот TFT который у меня хочет нормального тактирования вне зависимости от RESET.

 

 

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


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

Не знаю как в других, но OpenOCD шьет флеш-память с помощью маленькой вспомогательной программы в ОЗУ (другие думаю так же делают).

Далеко не все пользуются этой OpenOCD. Какой-нить клон j-link или тот же копеечный st-link уж явно по карману даже последнему нищеброду-эмбеддеру :)

 

Проще OpenOCD наверное некуда.

Т.е., под каждый камень нужно дорабатывать эту "маленькую прогу", чтобы она настраивала порты под конкретный проект сразу перед заливкой некого кода в ОЗУ, который потом шьет флэш?

Тогда да уж, действительно, как все просто ;)

 

 

А вот TFT который у меня хочет нормального тактирования вне зависимости от RESET.

Как я понял, речь идет о неком мифическом TFT, который в сбросе требует тактирования и без оного плохо себя чувствует. Все верно?

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


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

Классический интерфейс SW отладки всегда останавливает программу для обновления переменных в отладчике.

 

Нет. Например keil в Run моде спокойно обновляет значение переменных. В отличии от того же эклипса или воркбенча.

От последнего у меня одни слезы...

А кеил так и не делает нормальный редактор... ;(

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


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

От последнего у меня одни слезы... А кеил так и не делает нормальный редактор... ;(

Для меня эта ситуация напоминает известную отечественную сказку... в смысле "или дудочка или кувшинчик".

Сам пользуюсь Keil-ом, в целом привык. Хотя ни что не мешается пользоваться внешним редактором, Keil такие вещи понимает.

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


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

Далеко не все пользуются этой OpenOCD. Какой-нить клон j-link или тот же копеечный st-link уж явно по карману даже последнему нищеброду-эмбеддеру :)

А зачем он мне, если OpenOCD вполне справляется? Тем более я пользуюсь gcc/gdb, и не уверен, что st-link или j-link беспроблемно стыкуются с gdb.

 

Т.е., под каждый камень нужно дорабатывать эту "маленькую прогу", чтобы она настраивала порты под конкретный проект сразу перед заливкой некого кода в ОЗУ, который потом шьет флэш?

Зачем это делать? OpenOCD умеет заливать проги в несколько сотен разных процессоров, и не только заливать ;) Но если Вам хочется сделать что-то особенное, то нет проблем добавить несколько команд в скрипт :) Прогу в ОЗУ корректировать не нужно, она сама по себе.

 

А что там с st-link?

 

Речь идет о неком мифическом TFT, который в сбросе требует тактирования и без оного плохо себя чувствует. Я правильно понял?

Вообще-то без тактирования с включенным питанием драйверов любой ТФТ по идее медленно деградирует. В принципе, испортить его этим не получится - слишком мало времени занимает программирование, но все же мне приятнее, когда он в нормальном состоянии.

Изменено пользователем Шаманъ

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


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

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

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

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

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

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

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

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

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

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