Приветствую.
Продолжаю осваивать разработку под ARM в Eclipse и всё очень круто и нравится (если сравнивать с CrossWorks и Keil MDK-ARM), но в режиме дебага жутко тормозит. Чтоб перейти от одной точки останова к другой или просто при пошаговом исполнении необходимо время "на подумать". При запуске режима DEBUG также долго думает и что-то там выводит в консоль. Работаю с TI CCS Studio и Altera Nios II IDE, которые построены на базе Eclipse, там всё очень шустро.
Собственно вопрос, возможно ли задать какие-то настройки для Eclipse+OpenOCD, чтобы устранить это явление?
Спасибо.
Полная версия этой страницы: Eclipse + ARM Toolchain + OpenOCD
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Это выплёвыватся в консоль при подключении:
GNU ARM Eclipse 64-bit Open On-Chip Debugger 0.8.0-00063-gbda7f5c (2015-01-31-18:41)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10 kHz
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Started by GNU ARM Eclipse
Info : clock speed 10 kHz
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1788.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
undefined debug reason 7 - target needs reset
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
semihosting is enabled
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc, semihosting
Warn : Verification will fail since checksum in image (0x00000000) to be written to flash is different from calculated vector checksum (0xeffeef9e).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2228). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2431). Workaround: increase "set remotetimeout" in GDB
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc, semihosting
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc, semihosting
===== arm v7m registers
(0) r0 (/32): 0x00200FE0
(1) r1 (/32): 0x00106900
(2) r2 (/32): 0x100001B4
(3) r3 (/32): 0x00000000
(4) r4 (/32): 0x1000FF9C
(5) r5 (/32): 0x3456ABCD
(6) r6 (/32): 0x12345678
(7) r7 (/32): 0x1000FF30
(8) r8 (/32): 0x00000008
(9) r9 (/32): 0x2F975E05
(10) r10 (/32): 0x49AACFCA
(11) r11 (/32): 0xE79DDDF6
(12) r12 (/32): 0x1FFF1FF1
(13) sp (/32): 0x10001FFC
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0x1FFF0080
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x10001FFC
(18) psp (/32): 0x1AB2B464
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== Cortex-M DWT registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)
Тут вообще долго висит:
CODE
GNU ARM Eclipse 64-bit Open On-Chip Debugger 0.8.0-00063-gbda7f5c (2015-01-31-18:41)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10 kHz
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Started by GNU ARM Eclipse
Info : clock speed 10 kHz
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1788.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
undefined debug reason 7 - target needs reset
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
semihosting is enabled
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc, semihosting
Warn : Verification will fail since checksum in image (0x00000000) to be written to flash is different from calculated vector checksum (0xeffeef9e).
Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2228). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2431). Workaround: increase "set remotetimeout" in GDB
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc, semihosting
Info : JTAG tap: lpc1788.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc, semihosting
===== arm v7m registers
(0) r0 (/32): 0x00200FE0
(1) r1 (/32): 0x00106900
(2) r2 (/32): 0x100001B4
(3) r3 (/32): 0x00000000
(4) r4 (/32): 0x1000FF9C
(5) r5 (/32): 0x3456ABCD
(6) r6 (/32): 0x12345678
(7) r7 (/32): 0x1000FF30
(8) r8 (/32): 0x00000008
(9) r9 (/32): 0x2F975E05
(10) r10 (/32): 0x49AACFCA
(11) r11 (/32): 0xE79DDDF6
(12) r12 (/32): 0x1FFF1FF1
(13) sp (/32): 0x10001FFC
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0x1FFF0080
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x10001FFC
(18) psp (/32): 0x1AB2B464
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== Cortex-M DWT registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)
Тут вообще долго висит:
Код
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2228). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2431). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2432). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2431). Workaround: increase "set remotetimeout" in GDB
Ничего удивительного нет в "задумчивости" при выставленной частоте на TCK (тактовый сигнал JTAG):
Нормальной работы можно ожидать при частоте, ну скажем, от 1 МГц и выше.
У вас какой JTAG-кабель используется? Что-то в логе об этом не сказано.
Цитата(doom13 @ Mar 16 2015, 10:34) 
...
adapter speed: 10 kHz
...
adapter speed: 10 kHz
...
Нормальной работы можно ожидать при частоте, ну скажем, от 1 МГц и выше.
У вас какой JTAG-кабель используется? Что-то в логе об этом не сказано.
Спасибо, только почему она такая низкая получилась? Или надо было сразу скрипт конфига править?
Использую Amontec JTAG Key-2. Для Debug configurations прицепил скрипты из папки OpenOCD (ничего в них не менял, скрин тут, сообщение №7) для Interface и Target.
Ещё пробовал Olimex ARM-USB-Tiny-H, но всё было также.
Использую Amontec JTAG Key-2. Для Debug configurations прицепил скрипты из папки OpenOCD (ничего в них не менял, скрин тут, сообщение №7) для Interface и Target.
Ещё пробовал Olimex ARM-USB-Tiny-H, но всё было также.
Эти 2 скрипта можете приаттачить (конфиг для JTAGKey-2 и конкретного проца)?
Для JTAG Key-2 есть два скрипта, но использует ftdi/jtagkey2.cfg (ftdi_jtagkey2.cfg).
Расширение на txt поменял, а то не цепляет.
Расширение на txt поменял, а то не цепляет.
Для начала попробуйте осторожно поэкспериментировать со следующей строкой из lpc17xx.cfg:
adapter_khz 10
Измените частоту на 100, 200, 500, 1000, 3000 (можно и выше попробовать, но сомнительно). Каждый раз проверяйте в логе строку
и что перед ней / позади нее будет отрапортовано. Ну, и как при этом задумчивость изменяется, естественно.
А вообще, кое-что еще в CFG-файлах и постах из указанной другой темы мне показалось странным и несколько несоответствующим друг другу. Но об этом после, если будет интерес.
adapter_khz 10
Измените частоту на 100, 200, 500, 1000, 3000 (можно и выше попробовать, но сомнительно). Каждый раз проверяйте в логе строку
Цитата
...
adapter speed: 10 kHz
...
adapter speed: 10 kHz
...
и что перед ней / позади нее будет отрапортовано. Ну, и как при этом задумчивость изменяется, естественно.
А вообще, кое-что еще в CFG-файлах и постах из указанной другой темы мне показалось странным и несколько несоответствующим друг другу. Но об этом после, если будет интерес.
Цитата(Raven @ Mar 18 2015, 19:30)
Для начала попробуйте осторожно поэкспериментировать со следующей строкой из lpc17xx.cfg:
adapter_khz 10
Измените частоту на 100, 200, 500, 1000, 3000 (можно и выше попробовать, но сомнительно). Каждый раз проверяйте в логе строку
и что перед ней / позади нее будет отрапортовано. Ну, и как при этом задумчивость изменяется, естественно.
adapter_khz 10
Измените частоту на 100, 200, 500, 1000, 3000 (можно и выше попробовать, но сомнительно). Каждый раз проверяйте в логе строку
и что перед ней / позади нее будет отрапортовано. Ну, и как при этом задумчивость изменяется, естественно.
Спасибо, буду пробовать. Думал сегодня потестить, но не добрался до платы.
Цитата(Raven @ Mar 18 2015, 19:30)
А вообще, кое-что еще в CFG-файлах и постах из указанной другой темы мне показалось странным и несколько несоответствующим друг другу. Но об этом после, если будет интерес.
А что именно? Если это файл конфигурации для LPC1769, то всё правильно, начинал для LPC1769, сейчас разбираюсь на базе LPC1788.
Цитата(Raven @ Mar 18 2015, 19:30)
Для начала попробуйте осторожно поэкспериментировать со следующей строкой из lpc17xx.cfg:
adapter_khz 10
Измените частоту на 100, 200, 500, 1000, 3000 (можно и выше попробовать, но сомнительно). Каждый раз проверяйте в логе строку
adapter_khz 10
Измените частоту на 100, 200, 500, 1000, 3000 (можно и выше попробовать, но сомнительно). Каждый раз проверяйте в логе строку
Спасибо, в ней проблема была. Поставил 100 заработало уже нормально, остановился на 1000, думаю достаточно. Работает очень даже шустро.
Приветствую.
Вопрос в следующем: запускаю debag и стартую програму - всё работает нормально, если поставить breakpoint, то после запуска появляются какие-то тормоза в работе процессора (LPC1788). Замечено на работе Ethernet, с ПК посылаются сообщения на которые должен быть ответ, при отправке ответа (возможно при приёме) иногда есть непонятная задержка. Используется Olimex ARM-USB-Tiny-H.
В чём может быть проблема?
Вопрос в следующем: запускаю debag и стартую програму - всё работает нормально, если поставить breakpoint, то после запуска появляются какие-то тормоза в работе процессора (LPC1788). Замечено на работе Ethernet, с ПК посылаются сообщения на которые должен быть ответ, при отправке ответа (возможно при приёме) иногда есть непонятная задержка. Используется Olimex ARM-USB-Tiny-H.
В чём может быть проблема?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.