nanorobot 6 19 мая, 2017 Опубликовано 19 мая, 2017 (изменено) · Жалоба Отлаживаю дивайс на STM32 с помощью JLink. Иногда требуется "запаузить" отладку, посмотреть состояние переменных и т.п. Если момент паузы приходится когда на силовую часть подано напряжение (с ЦАПа), резисторы начинают гореть. Есть ли возможность запретить остановку прогаммы JLink-ом на каком то интервале программного кода? Изменено 19 мая, 2017 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 136 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Навряд ли. Но можно наставить точки останова в безопасные места и включать/отключать их всех сразу на всем скаку иконкой "Skip all breakpoints (Ctrl+Alt+B )" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 6 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Навряд ли. Но можно наставить точки останова в безопасные места и включать/отключать их всех сразу на всем скаку иконкой "Skip all breakpoints (Ctrl+Alt+B )" Переключение "Skip all breakpoints" У меня вызывет какие то неясные сбои в выполнении программы. Не каждый раз, но достаточно часто. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 236 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Есть ли возможность запретить остановку прогаммы JLink-ом на каком то интервале программного кода? Например IAR позволяет написать макросы execUserExecutionStarted() и execUserExecutionStopped(), которые он будет вызывать при старте и остановке выполнения кода. А в них можно сделать переключение каких-то пинов на безопасные значения - при стопе и восстановление их значений - при старте. Может и Ваш компилятор это умеет. Смотреть поддержку C-SPY. Насчёт запрета остановки - не знаю - читайте раздел мануала на свой МК, описывающий отладочный интерфейс (у STM32 называется DBG). Переключение "Skip all breakpoints" У меня вызывет какие то неясные сбои в выполнении программы. Не каждый раз, но достаточно часто. При таких операциях с бряками происходит пауза выполнения кода. Вероятно что-то у Вас критично к этому. Например - какая-то периферия при останове отладчиком у Вас продолжает работать, а программа не рассчитана на это. Тактирование многой периферии можно отключать при останове МК. Для этого есть соответствующие биты в DBG. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVI-crak 0 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Есть ли возможность запретить остановку прогаммы 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 1 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба А у ARM же есть режим отладки monitor mode вроде j-link поддерживает https://www.segger.com/monitor-mode-debugging.html Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Timmy 1 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Отлаживаю дивайс на STM32 с помощью JLink. Иногда требуется "запаузить" отладку, посмотреть состояние переменных и т.п. Если момент паузы приходится когда на силовую часть подано напряжение (с ЦАПа), резисторы начинают гореть. Есть ли возможность запретить остановку прогаммы JLink-ом на каком то интервале программного кода? Можно включить watchdog, который быстро перезагрузит процессор при неожиданной остановке. А в тех местах, где остановка разрешена, можно устанавливать бит блокировки watchdoga при входе в отладчик. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Иногда требуется "запаузить" отладку, посмотреть состояние переменных и т.п. Если момент паузы приходится когда на силовую часть подано напряжение (с ЦАПа), резисторы начинают гореть. Позволю себе немного по-умничать: © "Поздно пить боржоми, когда ..." ;) Cамый надежный способ - аппаратный! Схема не должна ничего жечь, если проц не прошит, прошит кривой прошивкой (где-то в коде завис) или находится в принудительном сбросе. Аппаратно это реализуется подтяжкой ответственных пинов к нужному уровню внешними резисторами (идеал - все пины куда-то подтянуть, а неиспользуемые бросить на землю). Железобетонное и очень простое решение! Более сложные ситуации требуют применения внешних "сторожевых систем", которые должны своевременно "кормиться" процом. Это полезно на случай, если проц уже успел проинициализировать порты, но где-то вдруг завис. Но все нужно учитывать заранее - еще на этапе проектирования принципиальной схемы B) Если используются внешние ЦАПы или т.п., то должен быть предусмотрен принудительный сброс ЦАП или вообще отключение его питания или его выхода через соотв. ключ (например, реле). Вообще, все внешние силовые узлы обычно имеют вход разрешения, который в таких случаях очень удобно использовать, дабы не мудрить с отключением питания всей "силы". Если "сила" самодельная, то это нужно предусматривать в обязательном порядке - вход разрешения "силы" должен быть предусмотрен в любом нормальном силовом девайсе! Более того это очень полезно при смене прошивки через JTAG (SWD), т. к. в процессе прошивки все порты "висят" в воздухе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Более того это очень полезно при смене прошивки через JTAG (SWD), т. к. в процессе прошивки все порты "висят" в воздухе. Вашу мысль про устойчивость на аппаратном уровне поддерживаю, но чего это они все "в воздухе висят" во время программирования? Разве что инструмент программирования очень простой. В том же OpenOCD можно проинициализировать что угодно, и как надо (я, например, LTDC запускаю, чтобы матрицу не мучать во время программирования - показывает синенький экран :)). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба но чего это они все "в воздухе висят" во время программирования? Насколько мне известно, в процессе прошивки тактирование cpu и всей периферии отключается. Поэтому, если пин никуда не притянут снаружи, на нем может быть что угодно! А что именно - уже зависит от опыта схемотехника ;) Разве что инструмент программирования очень простой.Для банальной смены прошивки не вижу смысла использовать сложные инструменты. я, например, LTDC запускаю, чтобы матрицу не мучать во время программирования - показывает синенький экран А я просто притянул вход RST к нулю внешним резистором, и вход контроллера питания подсветки тоже притянул в состояние, соотв. отключению. Т.е. при прошивке экран просто полностью гаснет ))) Ну и после подачи питания только что спаянного устройства (камень прошивается внутрисхемно) экран черный. По теме: я не внимательно прочитал вопрос ТС, поэтому поправлюсь: поможет использование передачи выбранных переменных по USART или мой любимый способ - Segger SystemViewer (очень удобно, если используется rtos). Впрочем, это тут уже прозвучало :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Насколько мне известно, в процессе прошивки тактирование cpu и всей периферии отключается. Не знаю как в других, но OpenOCD шьет флеш-память с помощью маленькой вспомогательной программы в ОЗУ (другие думаю так же делают). Так что все работает, более того можно в скриптах включить PLL и получить приличное ускорение верификации программы. Для банальной смены прошивки не вижу смысла использовать сложные инструменты. Проще OpenOCD наверное некуда. А я просто притянул вход RST к нулю внешним резистором, и вход контроллера питания подсветки тоже притянул в состояние, соотв. отключению. Подсветка не при делах - она ничего не портит (ну кроме разве что внешнего вида). А вот TFT который у меня хочет нормального тактирования вне зависимости от RESET. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Не знаю как в других, но OpenOCD шьет флеш-память с помощью маленькой вспомогательной программы в ОЗУ (другие думаю так же делают). Далеко не все пользуются этой OpenOCD. Какой-нить клон j-link или тот же копеечный st-link уж явно по карману даже последнему нищеброду-эмбеддеру :) Проще OpenOCD наверное некуда. Т.е., под каждый камень нужно дорабатывать эту "маленькую прогу", чтобы она настраивала порты под конкретный проект сразу перед заливкой некого кода в ОЗУ, который потом шьет флэш? Тогда да уж, действительно, как все просто ;) А вот TFT который у меня хочет нормального тактирования вне зависимости от RESET. Как я понял, речь идет о неком мифическом TFT, который в сбросе требует тактирования и без оного плохо себя чувствует. Все верно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RadiatoR 2 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба Классический интерфейс SW отладки всегда останавливает программу для обновления переменных в отладчике. Нет. Например keil в Run моде спокойно обновляет значение переменных. В отличии от того же эклипса или воркбенча. От последнего у меня одни слезы... А кеил так и не делает нормальный редактор... ;( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 19 мая, 2017 Опубликовано 19 мая, 2017 · Жалоба От последнего у меня одни слезы... А кеил так и не делает нормальный редактор... ;( Для меня эта ситуация напоминает известную отечественную сказку... в смысле "или дудочка или кувшинчик". Сам пользуюсь Keil-ом, в целом привык. Хотя ни что не мешается пользоваться внешним редактором, Keil такие вещи понимает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Шаманъ 1 19 мая, 2017 Опубликовано 19 мая, 2017 (изменено) · Жалоба Далеко не все пользуются этой OpenOCD. Какой-нить клон j-link или тот же копеечный st-link уж явно по карману даже последнему нищеброду-эмбеддеру :) А зачем он мне, если OpenOCD вполне справляется? Тем более я пользуюсь gcc/gdb, и не уверен, что st-link или j-link беспроблемно стыкуются с gdb. Т.е., под каждый камень нужно дорабатывать эту "маленькую прогу", чтобы она настраивала порты под конкретный проект сразу перед заливкой некого кода в ОЗУ, который потом шьет флэш? Зачем это делать? OpenOCD умеет заливать проги в несколько сотен разных процессоров, и не только заливать ;) Но если Вам хочется сделать что-то особенное, то нет проблем добавить несколько команд в скрипт :) Прогу в ОЗУ корректировать не нужно, она сама по себе. А что там с st-link? Речь идет о неком мифическом TFT, который в сбросе требует тактирования и без оного плохо себя чувствует. Я правильно понял? Вообще-то без тактирования с включенным питанием драйверов любой ТФТ по идее медленно деградирует. В принципе, испортить его этим не получится - слишком мало времени занимает программирование, но все же мне приятнее, когда он в нормальном состоянии. Изменено 19 мая, 2017 пользователем Шаманъ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться