Запрет остановки / паузы отладки, Linux / Eclipse / STM32F051 / JLink / SWD / OpenOCD Опции

[nanorobot]

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

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

[Сергей Борщ]

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

[nanorobot]

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

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

[jcxz]

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

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

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

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

[AVI-crak]

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

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

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

[KRS]

А у ARM же есть режим отладки monitor mode
вроде j-link поддерживает
https://www.segger.com/monitor-mode-debugging.html

[Timmy]

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

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

[Forger]

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

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

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

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

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

[Шаманъ]

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

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

[Forger]

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

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

Разве что инструмент программирования очень простой.

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

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

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

По теме:

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

[Шаманъ]

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

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

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

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

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

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

[Forger]

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

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

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

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

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

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

[RadiatoR]

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

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

[Forger]

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

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

[Шаманъ]

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

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

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

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

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

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

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

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

[Forger]

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

Все ясно с вами )))

Зачем это делать?

А кто будет настраивать порты на некие безопасные значения, чтобы не попалить силу, подключенную снаружи, пока шьется флэш?
Я вот всегда решаю это аппаратно, дабы не зависеть от всяких отладчиков/программаторов.

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

А то же самое - ST-LINK шьет абсолютно все STM8/STM32. В китаях идут по 100р за штучку. Обед в столовке и то дороже
Сам им давно не пользуюсь - медленный слишком.
У конторы, где работую, деньги есть на оригинальные j-link, а уж на его клонов и подавно.
Себе лично прикупиль несколько клонов, домой. Не разорился ни разу ))
Все встроенные в платки discovery st-link перешил на j-link, на сайте сеггера есть прошивка.

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

Ну-ну ...

[AHTOXA]

Все ясно с вами )))
А то же самое - ST-LINK шьет абсолютно все STM8/STM32. В китаях идут по 100р за штучку. Обед в столовке и то дороже

Вы бы хоть узнали, о чём судачите. Openocd - это программа. Она умеет работать и с ST-LINK, и с JLink, и с кучей других адаптеров.

[Forger]

Вы бы хоть узнали, о чём судачите. Openocd - это программа.

Вона как! А я то все думал, что она по-прежнему лишь с архаичным LPT-программаторами работает или чем-то на базе чипов FTDI USB-JTAG ...

[Шаманъ]

А кто будет настраивать порты на некие безопасные значения, чтобы не попалить силу, подключенную снаружи, пока шьется флэш?
Я вот всегда решаю это аппаратно, дабы не зависеть от всяких отладчиков/программаторов.

Эх, не читаете Вы то, что я пишу. Я не предлагал критически важные вещи делать зависимыми от программатора. В то же время иметь возможность установить в произвольное состояние любые порты/внутренние регистры/память это однозначно хорошо.

На счет кто будет настраивать, я тоже отвечал:

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

Ну-ну ...

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

[Forger]

Эх, не читаете Вы то, что я пишу. Я не предлагал критически важные вещи делать зависимыми от программатора.
В то же время иметь возможность установить в произвольное состояние любые порты/внутренние регистры/память это однозначно хорошо.

Мы отклоняемся от темы. В данном случае никакое программное решение с этим OpenOCD все равно толком не поможет, а спасет лишь это:
1) железное (аппаратное решение).
2) В случае с Keil можно прямо под отладчиком и работающем камне смотреть любые переменные и строить графики. Это отлично работает под j-link.
3) Использовать RTT (голый или под SystemViewer), это тот же пункт 3, но без Keil
4) UART + простейшая программка-терминал, или любой другой интерфейс с соотв. софтом.

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

Т.е. при активном сигнале сброса на TFT-панели она ведет себя таким образом?
Дайте ее название, мне стало даже любопытно ))

[Шаманъ]

Т.е. при активном сигнале сброса на TFT-панели она ведет себя таким образом?
Дайте ее название, мне стало даже любопытно ))

Да вроде как ничего особенного AT070TN92.2.

[Forger]

Да вроде как ничего особенного AT070TN92.2.

Когда его вывод RESET притянут к GND "полосы" тоже есть?

[arhiv6]

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

более того можно в скриптах включить PLL и получить приличное ускорение верификации программы.

А как это делается - что-то пишется в память по адресам, где находятся регистры периферии? Можете привести примеры (или дать ссылку, где почитать), как этим пользоваться?

[Шаманъ]

Когда его вывод RESET притянут к GND "полосы" тоже есть?

Да без разницы. Такое впечатление, что с resetом это вообще не связано (может они его внутри подключить забыли ).

А как это делается - что-то пишется в память по адресам, где находятся регистры периферии? Можете привести примеры (или дать ссылку, где почитать), как этим пользоваться?

Да, пишется в память. Например, вот так:

CODE

$_TARGETNAME configure -event reset-init {
# Configure PLL to boost clock to HSI x 4 (64 MHz)
mww 0x40023804 0x08012008 ;# RCC_PLLCFGR 16 Mhz /8 (M) * 128 (N) /4(P)
mww 0x40023C00 0x00000102 ;# FLASH_ACR = PRFTBE | 2(Latency)
mmw 0x40023800 0x01000000 0 ;# RCC_CR |= PLLON
sleep 10 ;# Wait for PLL to lock
mmw 0x40023808 0x00001000 0 ;# RCC_CFGR |= RCC_CFGR_PPRE1_DIV2
mmw 0x40023808 0x00000002 0 ;# RCC_CFGR |= RCC_CFGR_SW_PLL

# Boost JTAG frequency
adapter_khz 8000

#Confgure PLL SAI to clock LTDC (to prevend TFT degradation during flash loading)
mww 0x40023888 0x69011800 ;# RCC_PLLSAICFGR LTDC clock = 16 Mhz /8 (M) * 96 (N) / 6®
mmw 0x40023800 0x10000000 0 ;# RCC_CR |= PLLSAION
sleep 10 ;# Wait for PLL to lock
mmw 0x40023830 0x000001E3 0 ;# AHB1ENR Enable GPIO A,B,F,G,H,I
# Configure GPIO A
mww 0x40020000 0xA8000080 ;# MODER
mww 0x40020008 0xFC0000C0 ;# OSPEED
mww 0x40020020 0x00E00000 ;# AFRL
# Configure GPIO B
mww 0x40020400 0x000A0280 ;# MODER
mww 0x40020408 0x000F00C0 ;# OSPEED
mww 0x40020424 0x000000EE ;# AFRH
# Configure GPIO F
mww 0x40021400 0x00100000 ;# MODER DE=OUTPUT
mww 0x40021408 0x00000000 ;# OSPEED
# Configure GPIO G
mww 0x40021800 0x0280A000 ;# MODER
mww 0x40021808 0x03C0F000 ;# OSPEED
mww 0x40021820 0xEE000000 ;# AFRL
mww 0x40021824 0x0009E000 ;# AFRH
# Configure GPIO H
mww 0x40021C00 0xAAA80000 ;# MODER
mww 0x40021C08 0xFFFC0000 ;# OSPEED
mww 0x40021C24 0xEEEEEEE0 ;# AFRH
# Configure GPIO I
mww 0x40022000 0x0028002A ;# MODER
mww 0x40022008 0x003C003F ;# OSPEED
mww 0x40022020 0x00000EEE ;# AFRL
mww 0x40022024 0x00000EE0 ;# AFRH

mmw 0x40023844 0x04000000 0 ;# APB2ENR |= LTDC

#Configure LTDC
mww 0x40016808 0x00270013 ;# SSCR
mww 0x4001680C 0x002D0016 ;# BPCR
mww 0x40016810 0x034D01F6 ;# AWCR
mww 0x40016814 0x041F020C ;# TWCR
mww 0x4001682C 0x000000FF ;# BCCR
mmw 0x40016818 0x00002220 0 ;# GCR
mmw 0x40016818 0x00000001 0 ;# GCR
}

Команда
mww addr word
записывает слово word в память по адресу addr,
команда
mmw addr set clear
модифицирует слово по адресу addr в соответствии с битовыми масками set и clear

[Forger]

Да без разницы. Такое впечатление, что с resetом это вообще не связано (может они его внутри подключить забыли ).

Вот уж засада
Я бы в таком случае сделал бы коммутируемым питание панели от пина проца, т. е. в дефолте на голом проце питание на панель не идет.

[AlexandrY]

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

Да не проблема.
В Cortex-M on-chip breakpoints можно поставить только в области 0x00000000 - 0x1fffffff.
Перенесите код который нельзя прерывать в RAM и не сможете там поставить on-chip breakpoints.
Софтварные брикпойнты, конечно, при этом надо в J-Link запретить.

[nanorobot]

А как это делается - что-то пишется в память по адресам, где находятся регистры периферии? Можете привести примеры (или дать ссылку, где почитать), как этим пользоваться?

Сорри, arhiv6, Вы автор статьи на изи об OpenOCD и SEGGER RTT? Хочется вопросов пару задать. Но - завтра.

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