Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
Am 22.07.2011 20:02, schrieb Andreas Fritiofson: Your RLink reports the same firmware version as my STM32Primer does. If that means they are identical, I should be able to reproduce, but I can't. Maybe it depends on the version of libusb? I'm using OpenSuse 11.4. Here's what the package manager tells about libusb: $ zypper se libusb S | Name| Zusammenfassung | Typ --+-+---+--- i | libusb-0_1-4| libusb-1.0 Compatibility Library for libusb-0.1 | Paket | libusb-1_0 | USB Library | Quellpaket i | libusb-1_0-0| USB Library | Paket i | libusb-1_0-devel| USB Library | Paket | libusb-compat | libusb-1.0 Compatibility Layer for libusb-0.1 | Quellpaket i | libusb-compat-devel | libusb-1.0 Compatibility Layer for libusb-0.1 | Paket | libusbmuxd-devel| Development files for libusbmuxd | Paket i | libusbmuxd1 | A library to abstract socket/protocol communication to the usbmuxd daemon | Paket | libusbprog0 | USBprog Library | Paket Also I don't have a Windows machine to test on. Regardless, I still can't understand how my patches can make it fail as early as during init, though. I see now that the linux log hints that it doesn't fail in the same place. Do you have a debug log for that too? Here's the debug log on Linux with your Rlink patches 1/7 to 4/7 applied. Runs as expected: Open On-Chip Debugger 0.5.0-dev-00959-gd6c42bf (2011-07-22-00:16) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html User : 11 1 command.c:557 command_print(): debug_level: 3 Debug: 12 1 configuration.c:45 add_script_search_dir(): adding tcl/ Debug: 13 1 configuration.c:45 add_script_search_dir(): adding /root/.openocd Debug: 14 1 configuration.c:45 add_script_search_dir(): adding /usr/local/share/openocd/site Debug: 15 1 configuration.c:45 add_script_search_dir(): adding /usr/local/share/openocd/scripts Debug: 16 1 configuration.c:87 find_file(): found tcl//interface/rlink.cfg Debug: 17 1 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_interface rlink Debug: 18 1 command.c:151 script_debug(): command - interface ocd_interface rlink Warn : 20 1 adapter.c:167 handle_interface_command(): Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : 21 1 transport.c:123 allow_transports(): only one transport option; autoselect 'jtag' Debug: 22 1 command.c:364 register_command_handler(): registering 'ocd_jtag_flush_queue_sleep'... Debug: 23 1 command.c:364 register_command_handler(): registering 'ocd_jtag_rclk'... Debug: 24 1 command.c:364 register_command_handler(): registering 'ocd_jtag_ntrst_delay'... Debug: 25 1 command.c:364 register_command_handler(): registering 'ocd_jtag_ntrst_assert_width'... Debug: 26 1 command.c:364 register_command_handler(): registering 'ocd_scan_chain'... Debug: 27 1 command.c:364 register_command_handler(): registering 'ocd_jtag_reset'... Debug: 28 1 command.c:364 register_command_handler(): registering 'ocd_runtest'... Debug: 29 1 command.c:364 register_command_handler(): registering 'ocd_irscan'... Debug: 30 1 command.c:364 register_command_handler(): registering 'ocd_verify_ircapture'... Debug: 31 1 command.c:364 register_command_handler(): registering 'ocd_verify_jtag'... Debug: 32 2 command.c:364 register_command_handler(): registering 'ocd_tms_sequence'... Debug: 33 2 command.c:364 register_command_handler(): registering 'ocd_wait_srst_deassert'... Debug: 34 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 35 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 36 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 37 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 38 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 39 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 40 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 41 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 42 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 43 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 44 2 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 45 2 command.c:364
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
Am 22.07.2011 15:10, schrieb Tomek CEDRO: On Fri, Jul 22, 2011 at 9:59 AM, Peter Hornpeter.h...@bluewin.ch wrote: Besides the RLink I also have an Olimex ARM-USB-OCD adpater. On Windows, stepping with the Olimex is considerably faster than with the RLink. On Linux both adapters are on par. I'm Using the same STM32 board and OCD-Version in all cases, so the cause for the slow stepping must be related to the RLink driver. ...and the OS-specific USB stack or RLink architecture itself. If you chceck the timings on OpenOCD (windows/linux) and RIDE (windows) then comparison should reviel the driver and the os-usb-stack quality, but if the timings are similar that could be matter of device/firmware design. It would be nice to see such comparison :-) Hi Tomek Without taking exact measurements, my impression is that the RLink performs about the same with RIDE on Windows and OpenOCD on Linux. FWIW RLink uses the Jungo driver on Windows. Sadly I don't have such a cool USB protocol analyzer like you to take measurements. Also the SWD part of the protocol still waits to be solved [1] :-) SWD would be really nice to have. Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
On Jul 24, 2011 8:54 PM, Peter Horn peter.h...@bluewin.ch wrote: Hi Tomek Without taking exact measurements, my impression is that the RLink performs about the same with RIDE on Windows and OpenOCD on Linux. FWIW RLink uses the Jungo driver on Windows. Just for info - Jungo is used on winxp and below - vista and newer now use a winusb based driver. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
On Fri, Jul 22, 2011 at 12:29 AM, Peter Horn peter.h...@bluewin.ch wrote: Am 19.07.2011 22:43, schrieb Peter Horn: Last time I've used OpenOCD with RLink stepping was awfully slow, about 3 seconds or more per step. This was some weeks ago and on Windows / Mingw. On Linux, stepping is considerably faster both with and without your patches, so I have to try the current version again on Windows. Stepping is still slow on Windows. Stepping speed is not affected much by these patches since it depends largely on latency, not throughput. These patches fixes a throughput problem. Cortex-M3 stepping is really dependent on latency because, for some reason, each register is read atomically upon debug entry, plus one atomic restore of a debug register (for DCC purposes) per register. Just reading core registers takes ~0.3 s on my linux system using the primer. I have now also applied the RLink RLink interface speedup and fixes patch series and run into some problems: On Linux with the standalone RLink I get: Open On-Chip Debugger 0.5.0-dev-00959-gd6c42bf-dirty (2011-07-21-23:47) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/**doxygen/bugs.htmlhttp://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 1000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq Info : clock speed 375 kHz Error: Read of endpoint 2 returned -75, expected 17 Error: dtc_run_download: Value too large for defined data type Patches 1/7 to 4/7 work ok, the problem is caused by patch 5/7 On Windows using the embedded RLink, OpenOCD: Open On-Chip Debugger 0.5.0-dev-snapshot (2011-07-21-07:10) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/**doxygen/bugs.htmlhttp://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 1000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq Error: USB read error: libusb0-dll:err [_usb_reap_async] timeout error in procedure 'init' Can you post debug logs (add -d on command line)? There seems to be an known issue with libusb-win32: http://permalink.gmane.org/**gmane.comp.lib.libusb.devel.**windows/505http://permalink.gmane.org/gmane.comp.lib.libusb.devel.windows/505 BTW I'm using libusb-win32 1.2.4.0 Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
Am 22.07.2011 11:42, schrieb Andreas Fritiofson: Stepping is still slow on Windows. Stepping speed is not affected much by these patches since it depends largely on latency, not throughput. These patches fixes a throughput problem. Cortex-M3 stepping is really dependent on latency because, for some reason, each register is read atomically upon debug entry, plus one atomic restore of a debug register (for DCC purposes) per register. Just reading core registers takes ~0.3 s on my linux system using the primer. Besides the RLink I also have an Olimex ARM-USB-OCD adpater. On Windows, stepping with the Olimex is considerably faster than with the RLink. On Linux both adapters are on par. I'm Using the same STM32 board and OCD-Version in all cases, so the cause for the slow stepping must be related to the RLink driver. I have now also applied the RLink RLink interface speedup and fixes patch series and run into some problems: On Linux with the standalone RLink I get: Open On-Chip Debugger 0.5.0-dev-00959-gd6c42bf-dirty (2011-07-21-23:47) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/__doxygen/bugs.html http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 1000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq Info : clock speed 375 kHz Error: Read of endpoint 2 returned -75, expected 17 Error: dtc_run_download: Value too large for defined data type Patches 1/7 to 4/7 work ok, the problem is caused by patch 5/7 On Windows using the embedded RLink, OpenOCD: Open On-Chip Debugger 0.5.0-dev-snapshot (2011-07-21-07:10) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/__doxygen/bugs.html http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 1000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq Error: USB read error: libusb0-dll:err [_usb_reap_async] timeout error in procedure 'init' Can you post debug logs (add -d on command line)? At the moment I can provide you the debug log on Windows. Linux log will follow. Open On-Chip Debugger 0.5.0-dev-snapshot (2011-07-21-07:10) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html User : 11 0 command.c:557 command_print(): debug_level: 3 Debug: 12 0 configuration.c:45 add_script_search_dir(): adding tcl Debug: 13 0 configuration.c:45 add_script_search_dir(): adding w:\openocd\src\.. Debug: 14 16 configuration.c:45 add_script_search_dir(): adding w:/openocd/src/../share/openocd/scripts Debug: 15 16 configuration.c:87 find_file(): found tcl/interface/rlink.cfg Debug: 16 16 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_interface rlink Debug: 17 16 command.c:151 script_debug(): command - interface ocd_interface rlink Warn : 19 16 adapter.c:167 handle_interface_command(): Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : 20 16 transport.c:123 allow_transports(): only one transport option; autoselect 'jtag' Debug: 21 16 command.c:364 register_command_handler(): registering 'ocd_jtag_flush_queue_sleep'... Debug: 22 16 command.c:364 register_command_handler(): registering 'ocd_jtag_rclk'... Debug: 23 16 command.c:364 register_command_handler(): registering 'ocd_jtag_ntrst_delay'... Debug: 24 16 command.c:364 register_command_handler(): registering 'ocd_jtag_ntrst_assert_width'... Debug: 25 16 command.c:364 register_command_handler(): registering 'ocd_scan_chain'... Debug: 26 16 command.c:364 register_command_handler(): registering 'ocd_jtag_reset'... Debug: 27 16 command.c:364 register_command_handler(): registering 'ocd_runtest'... Debug: 28 16 command.c:364 register_command_handler(): registering 'ocd_irscan'... Debug: 29 16 command.c:364 register_command_handler(): registering 'ocd_verify_ircapture'... Debug: 30 16 command.c:364 register_command_handler(): registering 'ocd_verify_jtag'... Debug: 31 16 command.c:364 register_command_handler(): registering 'ocd_tms_sequence'... Debug: 32 16 command.c:364 register_command_handler(): registering 'ocd_wait_srst_deassert'... Debug: 33 16 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 34 16 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 35 16 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 36 16 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 37 16 command.c:364 register_command_handler():
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
On Fri, Jul 22, 2011 at 11:59 AM, Peter Horn peter.h...@bluewin.ch wrote: Patches 1/7 to 4/7 work ok, the problem is caused by patch 5/7 On Windows using the embedded RLink, OpenOCD: Open On-Chip Debugger 0.5.0-dev-snapshot (2011-07-21-07:10) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/**__doxygen/bugs.htmlhttp://openocd.berlios.de/doc/__doxygen/bugs.html http://openocd.berlios.de/**doc/doxygen/bugs.htmlhttp://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 1000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq Error: USB read error: libusb0-dll:err [_usb_reap_async] timeout error in procedure 'init' At the moment I can provide you the debug log on Windows. Linux log will follow. snip Debug: 188 125 rlink.c:1565 rlink_init(): Opened device, pHDev = 00eb3560 Debug: 189 125 rlink.c:1585 rlink_init(): interface claimed! Error: 190 407 rlink.c:1628 rlink_init(): USB read error: libusb0-dll:err [_usb_reap_async] timeout error Debug: 191 407 command.c:638 run_command(): Command failed with error code -4 User : 192 407 command.c:679 command_run_line(): in procedure 'init' Peter I don't see how this error could be caused by my patches. If I'm not mistaken, none of them have run at this point. It fails during init, and that code is unchanged with the exception of some indentation fixes and AFAICT they're OK. Can you reverify with unpatched tree? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
Am 22.07.2011 13:36, schrieb Andreas Fritiofson: I don't see how this error could be caused by my patches. If I'm not mistaken, none of them have run at this point. It fails during init, and that code is unchanged with the exception of some indentation fixes and AFAICT they're OK. Can you reverify with unpatched tree? /Andreas Hi Andreas I did: $ cp openocd-rlink-patched openocd $ cd openocd $ git reset --hard HEAD $ make clean $ make all $ src/openocd.exe -d -s tcl -f interface/rlink.cfg -f board/stm3210c_eval.cfg This yields: Open On-Chip Debugger 0.5.0-dev-snapshot (2011-07-22-12:47) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html User : 11 15 command.c:557 command_print(): debug_level: 3 Debug: 12 15 configuration.c:45 add_script_search_dir(): adding tcl Debug: 13 15 configuration.c:45 add_script_search_dir(): adding w:\openocd\src\.. Debug: 14 15 configuration.c:45 add_script_search_dir(): adding w:/openocd/src/../share/openocd/scripts Debug: 15 15 configuration.c:87 find_file(): found tcl/interface/rlink.cfg Debug: 16 15 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_interface rlink Debug: 17 15 command.c:151 script_debug(): command - interface ocd_interface rlink Warn : 19 15 adapter.c:167 handle_interface_command(): Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : 20 15 transport.c:123 allow_transports(): only one transport option; autoselect 'jtag' Debug: 21 15 command.c:364 register_command_handler(): registering 'ocd_jtag_flush_queue_sleep'... Debug: 22 15 command.c:364 register_command_handler(): registering 'ocd_jtag_rclk'... Debug: 23 15 command.c:364 register_command_handler(): registering 'ocd_jtag_ntrst_delay'... Debug: 24 15 command.c:364 register_command_handler(): registering 'ocd_jtag_ntrst_assert_width'... Debug: 25 15 command.c:364 register_command_handler(): registering 'ocd_scan_chain'... Debug: 26 15 command.c:364 register_command_handler(): registering 'ocd_jtag_reset'... Debug: 27 15 command.c:364 register_command_handler(): registering 'ocd_runtest'... Debug: 28 15 command.c:364 register_command_handler(): registering 'ocd_irscan'... Debug: 29 15 command.c:364 register_command_handler(): registering 'ocd_verify_ircapture'... Debug: 30 15 command.c:364 register_command_handler(): registering 'ocd_verify_jtag'... Debug: 31 15 command.c:364 register_command_handler(): registering 'ocd_tms_sequence'... Debug: 32 15 command.c:364 register_command_handler(): registering 'ocd_wait_srst_deassert'... Debug: 33 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 34 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 35 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 36 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 37 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 38 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 39 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 40 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 41 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 42 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 43 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 44 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 45 15 command.c:364 register_command_handler(): registering 'ocd_jtag'... Debug: 46 15 command.c:364 register_command_handler(): registering 'ocd_svf'... Debug: 47 15 command.c:364 register_command_handler(): registering 'ocd_xsvf'... Debug: 48 15 configuration.c:87 find_file(): found tcl/board/stm3210c_eval.cfg Debug: 49 15 configuration.c:87 find_file(): found tcl/target/stm32.cfg Debug: 50 15 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_adapter_khz 1000 Debug: 51 15 command.c:151 script_debug(): command - adapter_khz ocd_adapter_khz 1000 Debug: 53 15 core.c:1639 jtag_config_khz(): handle jtag khz Debug: 54 15 core.c:1602 adapter_khz_to_speed(): convert khz to interface specific speed value Debug: 55 15 core.c:1602 adapter_khz_to_speed(): convert khz to interface specific speed value User : 56 15 command.c:557 command_print(): 1000 kHz Debug: 57 15 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_adapter_nsrst_delay 100 Debug: 58 15 command.c:151 script_debug(): command - adapter_nsrst_delay ocd_adapter_nsrst_delay 100 User : 60 15 command.c:557 command_print(): adapter_nsrst_delay: 100 Debug: 61 31 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_jtag_ntrst_delay 100 Debug: 62 31 command.c:151 script_debug(): command - jtag_ntrst_delay ocd_jtag_ntrst_delay 100 User : 64 31
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
On Fri, Jul 22, 2011 at 9:59 AM, Peter Horn peter.h...@bluewin.ch wrote: Besides the RLink I also have an Olimex ARM-USB-OCD adpater. On Windows, stepping with the Olimex is considerably faster than with the RLink. On Linux both adapters are on par. I'm Using the same STM32 board and OCD-Version in all cases, so the cause for the slow stepping must be related to the RLink driver. ...and the OS-specific USB stack or RLink architecture itself. If you chceck the timings on OpenOCD (windows/linux) and RIDE (windows) then comparison should reviel the driver and the os-usb-stack quality, but if the timings are similar that could be matter of device/firmware design. It would be nice to see such comparison :-) Also the SWD part of the protocol still waits to be solved [1] :-) Best regars! :-) Tomek [1] http://files.tomek.cedro.info/electronics/arm/cortex/stm32/rlinkre/ -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
On Fri, Jul 22, 2011 at 2:55 PM, Peter Horn peter.h...@bluewin.ch wrote: Am 22.07.2011 13:36, schrieb Andreas Fritiofson: I don't see how this error could be caused by my patches. If I'm not mistaken, none of them have run at this point. It fails during init, and that code is unchanged with the exception of some indentation fixes and AFAICT they're OK. Can you reverify with unpatched tree? /Andreas Hi Andreas I did: $ cp openocd-rlink-patched openocd $ cd openocd $ git reset --hard HEAD $ make clean $ make all $ src/openocd.exe -d -s tcl -f interface/rlink.cfg -f board/stm3210c_eval.cfg This yields: Open On-Chip Debugger 0.5.0-dev-snapshot (2011-07-22-12:47) snip Debug: 188 125 rlink.c:1595 rlink_init(): Opened device, pHDev = 00ebf528 Debug: 189 125 rlink.c:1615 rlink_init(): interface claimed! Debug: 190 203 rlink.c:1661 rlink_init(): RLink firmware version: 0.0.3 Your RLink reports the same firmware version as my STM32Primer does. If that means they are identical, I should be able to reproduce, but I can't. Maybe it depends on the version of libusb? Also I don't have a Windows machine to test on. Regardless, I still can't understand how my patches can make it fail as early as during init, though. I see now that the linux log hints that it doesn't fail in the same place. Do you have a debug log for that too? Debug: 279 2250 rlink.c:507 dtc_run_download(): : 55/22 Debug: 280 2359 rlink.c:507 dtc_run_download(): : 55/22 the last few lines continue forever. That's OpenOCD polling the target. /Andreas /*** * Copyright (C) 2005 by Dominic Rath* * dominic.r...@gmx.de * * * * Copyright (C) 2007,2008 Øyvind Harboe * * oyvind.har...@zylin.com * * * * Copyright (C) 2008 Rob Brown, Lou Deluxe * * r...@cobbleware.com, lou.openocd...@fixit.nospammail.net * * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * (at your option) any later version. * * * * This program is distributed in the hope that it will be useful, * * but WITHOUT ANY WARRANTY; without even the implied warranty of* * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * * GNU General Public License for more details. * * * * You should have received a copy of the GNU General Public License * * along with this program; if not, write to the * * Free Software Foundation, Inc., * * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. * ***/ #ifdef HAVE_CONFIG_H #include config.h #endif /* project specific includes */ #include jtag/interface.h #include jtag/commands.h #include rlink.h #include rlink_st7.h #include rlink_ep1_cmd.h #include rlink_dtc_cmd.h #include usb_common.h /* This feature is made useless by running the DTC all the time. When automatic, the LED is on whenever the DTC is running. Otherwise, USB messages are sent to turn it on and off. */ #undef AUTOMATIC_BUSY_LED /* This feature may require derating the speed due to reduced hold time. */ #undef USE_HARDWARE_SHIFTER_FOR_TMS #define INTERFACE_NAME RLink #define USB_IDVENDOR (0x138e) #define USB_IDPRODUCT (0x9000) #define USB_EP1OUT_ADDR (0x01) #define USB_EP1OUT_SIZE (16) #define USB_EP1IN_ADDR (USB_EP1OUT_ADDR | 0x80) #define USB_EP1IN_SIZE (USB_EP1OUT_SIZE) #define USB_EP2OUT_ADDR (0x02) #define USB_EP2OUT_SIZE (64) #define USB_EP2IN_ADDR (USB_EP2OUT_ADDR | 0x80) #define USB_EP2IN_SIZE (USB_EP2OUT_SIZE) #define USB_EP2BANK_SIZE (512) #define USB_TIMEOUT_MS (3 * 1000) #define DTC_STATUS_POLL_BYTE (ST7_USB_BUF_EP0OUT + 0xff) #define ST7_PD_NBUSY_LED ST7_PD0 #define ST7_PD_NRUN_LED ST7_PD1 /* low enables VPP at adapter header, high connects it to GND instead */ #define ST7_PD_VPP_SEL ST7_PD6 /* low: VPP = 12v, high: VPP = 5v */ #define ST7_PD_VPP_SHDN ST7_PD7 /* These pins are connected together */ #define ST7_PE_ADAPTER_SENSE_IN ST7_PE3 #define ST7_PE_ADAPTER_SENSE_OUT ST7_PE4 /* Symbolic mapping between port
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
Am 19.07.2011 22:43, schrieb Peter Horn: Hi Andreas I have access to a standalone Rlink, an Olimex STM32-P103 board and a Raisonance REva STM32 connectivity board which has an onboard Rlink. I've applied your patches and built OpenOCD on Linux with success. A quick test revealed no problems but the test program I've used is too small to see any speed differences when flashing. I can do more tests, some hints for what to look for would be welcome. Hi Andreas I recognized that I've applied only the five patches from the patch set concerning Flash program speedup through asynchronous algorithms when I did testing. This patch works for me without problems on Windows / Mingw and Linux, both with the embedded RLink of the Raisonance REva board as well as with a standalone RLink. Last time I've used OpenOCD with RLink stepping was awfully slow, about 3 seconds or more per step. This was some weeks ago and on Windows / Mingw. On Linux, stepping is considerably faster both with and without your patches, so I have to try the current version again on Windows. Stepping is still slow on Windows. I have now also applied the RLink RLink interface speedup and fixes patch series and run into some problems: On Linux with the standalone RLink I get: Open On-Chip Debugger 0.5.0-dev-00959-gd6c42bf-dirty (2011-07-21-23:47) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 1000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq Info : clock speed 375 kHz Error: Read of endpoint 2 returned -75, expected 17 Error: dtc_run_download: Value too large for defined data type Patches 1/7 to 4/7 work ok, the problem is caused by patch 5/7 On Windows using the embedded RLink, OpenOCD: Open On-Chip Debugger 0.5.0-dev-snapshot (2011-07-21-07:10) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'rlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 1000 kHz adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 cortex_m3 reset_config sysresetreq Error: USB read error: libusb0-dll:err [_usb_reap_async] timeout error in procedure 'init' There seems to be an known issue with libusb-win32: http://permalink.gmane.org/gmane.comp.lib.libusb.devel.windows/505 BTW I'm using libusb-win32 1.2.4.0 Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup, and fixes
Hi Andreas I have access to a standalone Rlink, an Olimex STM32-P103 board and a Raisonance REva STM32 connectivity board which has an onboard Rlink. I've applied your patches and built OpenOCD on Linux with success. A quick test revealed no problems but the test program I've used is too small to see any speed differences when flashing. I can do more tests, some hints for what to look for would be welcome. Last time I've used OpenOCD with RLink stepping was awfully slow, about 3 seconds or more per step. This was some weeks ago and on Windows / Mingw. On Linux, stepping is considerably faster both with and without your patches, so I have to try the current version again on Windows. Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup and fixes
Hello Andreas! Do you know what is the difference between JTAG (on Stm32Primer) and SWD (on Stm32Primer2) RLink interface? Would they run on existing driver? Do you have some kind of manual or technical specification? Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup and fixes
On 18 July 2011 11:13, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: This patch set fixes some general problems in the RLink interface driver. Most importantly it fixes a performance bug that have been causing decreased throughput. Speed test on a STM32 Primer (STM32F103 platform with built in RLink) with the following openocd.cfg --- great work - someone has been busy :) I have a tendency to leave these patches until after we make a formal 0.5 release - you have some significant changes included. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup and fixes
On Mon, Jul 18, 2011 at 4:03 PM, Spencer Oliver s...@spen-soft.co.ukwrote: On 18 July 2011 11:13, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: This patch set fixes some general problems in the RLink interface driver. Most importantly it fixes a performance bug that have been causing decreased throughput. Speed test on a STM32 Primer (STM32F103 platform with built in RLink) with the following openocd.cfg --- great work - someone has been busy :) I have a tendency to leave these patches until after we make a formal 0.5 release - you have some significant changes included. Yes it's best to put these on hold for 0.5.0. It needs some testing on the standalone RLink or other variants, I currently only have access to STM32 Primers. Also more thorough testing in general. Anyone feels like helping? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup and fixes
On Mon, Jul 18, 2011 at 2:33 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: Hello Andreas! Do you know what is the difference between JTAG (on Stm32Primer) and SWD (on Stm32Primer2) RLink interface? Would they run on existing driver? Do you have some kind of manual or technical specification? Other than the JTAG/SWD difference, I don't know. I don't have a Primer2 or any spec for the RLinks in general. I don't know if the docs are public or if the protocol was reverse engineered for the OpenOCD driver. I'm guessing that the SWD capable interface has some extra command but the same basic protocol. IIRC the standalone RLink we have at work can handle a number of other protocols too. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup and fixes
Le 18/07/2011 16:25, Andreas Fritiofson a écrit : Yes it's best to put these on hold for 0.5.0. It needs some testing on the standalone RLink or other variants, I currently only have access to STM32 Primers. Also more thorough testing in general. Anyone feels like helping? Hello Andreas, I have a standalone R-Link and a Keil STM32 board, but a very little knowledge of Openocd. What can I do to help the project ? Jean-Claude ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 0/7] RLink interface speedup and fixes
On Mon, Jul 18, 2011 at 4:59 PM, Jean-Claude Repetto jcr...@mxm.eu wrote: Le 18/07/2011 16:25, Andreas Fritiofson a écrit : Yes it's best to put these on hold for 0.5.0. It needs some testing on the standalone RLink or other variants, I currently only have access to STM32 Primers. Also more thorough testing in general. Anyone feels like helping? Hello Andreas, I have a standalone R-Link and a Keil STM32 board, but a very little knowledge of Openocd. What can I do to help the project ? Hi, great! Do you know how to *use* OpenOCD (as opposed to knowing its internals)? Otherwise it could be a good opportunity to learn! :) If you have a setup that's currently working for you, so you can program flash, debug and whatnot, and some knowledge (or willingness to learn) how to clone a git repository and building software from source, you can sure help with testing. Clone the openocd repository, checkout master, build it and start it up to see if it works. Then apply my patches, build it and then verify that you can still do everything that you could before. Try anything that comes to mind. Report any errors. Thanks, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
