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

Сообщение отредактировал nanorobot - May 19 2017, 05:43

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

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

Например IAR позволяет написать макросы execUserExecutionStarted() и execUserExecutionStopped(), которые он будет вызывать при старте и остановке выполнения кода.
А в них можно сделать переключение каких-то пинов на безопасные значения - при стопе и восстановление их значений - при старте.
Может и Ваш компилятор это умеет. Смотреть поддержку C-SPY.
Насчёт запрета остановки - не знаю - читайте раздел мануала на свой МК, описывающий отладочный интерфейс (у STM32 называется DBG).


При таких операциях с бряками происходит пауза выполнения кода. Вероятно что-то у Вас критично к этому.
Например - какая-то периферия при останове отладчиком у Вас продолжает работать, а программа не рассчитана на это.
Тактирование многой периферии можно отключать при останове МК. Для этого есть соответствующие биты в DBG.

Классический интерфейс 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

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

Позволю себе немного по-умничать: © "Поздно пить боржоми, когда ..."
Cамый надежный способ - аппаратный!
Схема не должна ничего жечь, если проц не прошит, прошит кривой прошивкой (где-то в коде завис) или находится в принудительном сбросе.
Аппаратно это реализуется подтяжкой ответственных пинов к нужному уровню внешними резисторами (идеал - все пины куда-то подтянуть, а неиспользуемые бросить на землю).
Железобетонное и очень простое решение!
Более сложные ситуации требуют применения внешних "сторожевых систем", которые должны своевременно "кормиться" процом.
Это полезно на случай, если проц уже успел проинициализировать порты, но где-то вдруг завис.

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

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

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

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

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

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


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

По теме:

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

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


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


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

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


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



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

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

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

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


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

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


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

Сообщение отредактировал Шаманъ - May 19 2017, 18:13