У меня возникла проблема с надежной настройкой отладки. Я видел другие темы на некоторых форумах по сети с похожим названием, но обстоятельства кажутся разными.причина 7 - цель требует сброса - ненадежная настройка отладки
Установка:
- Linux (Xubuntu) 64bit
- Eclipse CDT, Неон 4.6.0
- "GDB Hardware Debugging" плагин от затмения "установить новое программное обеспечение", сконфигурированный для сброса & задержки 3сек , остановка; Символы нагрузки (все галочки, ни пользовательских команд)
- рычажного ни-EABI-GCC 4.8.3 инструмент цепи
- OpenOCD, недавно скачал, работает в собственной консоли, сконфигурированный для моего точного MCU с скриптом предоставленной ими & st-link
- STM32L476RG MCU с жестким поплавком, который используется.
- ST-Link V2 отладчик (автономные)
Теперь, есть последовательность, с которой я, после некоторой борьбы каждый раз, может подключиться с помощью отладчика, но ступая и чтение переменных Безразлично» t работайте настолько надёжно, что я буду доверять тому, что вижу на секунду. Но даже дойти до того момента, когда стек вызовов не будет заполнен очевидными бессмысленными записями и только очень немногие из них, утомительно.
Пример:
- флэш-устройство с прошивкой. Это обычно работает без проблем.
- Запустить openocd.
- Начать отладку в Eclipse.
- OpenOcd показывает соединение, а затем говорит: «неопределенная причина отладки 7 - цель нуждается в сбросе»
- Независимо от того, чтобы нажать кнопку «возобновить» в Eclipse, чтобы программа прошла мимо фальшивого верхнего фрейма стека.
- Нажмите «suspend» (по-прежнему поддельный в callstack), затем «завершите».
- Ctrl + C из OpenOcd.
- Вручную (аппаратное) сбросить MCU stm32.
- Restart OpenOcd.
- Запустите отладку снова в Eclipse.
OpenOCD выход:
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
none separate
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.192646
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10076415
Info : flash size = 1024kbytes
undefined debug reason 7 - target needs reset
Теперь с некоторой удачей, я наконец-то есть соединение несколько рабочего отладчик, на некоторое время. Но это может потребовать некоторых повторений. Почему «нажмите возобновить» между ними, когда ясно, что соединение плохое? Не уверен, это, по-видимому, увеличивает вероятность того, что на следующей итерации у меня будет связь, много.
Возможно, соответствующее примечание: У MCU есть ЖК-дисплей, подключенный к нему, и из этого я могу видеть, когда он сбрасывается. По какой-то причине начальная отладка в Eclipse, по-видимому, не перезагружает устройство, хотя флажок сброса проверяется в конфигурации отладки. Если я открываю telnet-соединение с OpenOCD в терминале и выполняю «перезагрузку», устройство перезагружается.
Что может быть причиной нечетного поведения моей установки?
Попробуйте включить «reset halt» в вашем openocd .cfg или набрав «остановку сброса монитора» в gdb. –