Re: [OpenOCD-devel] Fwd: Re: Status of PIC32/mips support?
On 04/12/2012 03:59 PM, Vaclav Peroutka wrote: >> Only for comparing, >> how much time takes it for this command: " (gdb) monitor mdw 0xa000 >> 1024 " ?. >> >> For me about 6 seconds (jtag at 350Khz real). >> > Hello, I just tried it on another computer - Windows XP again. Result is > approximately 30 seconds @ 200kHz real. I made a snapshot on oscilloscope (I > can send it here, too). I see that between JTAG transfers there are delays of > around 600us. I then experimentally increased TCK to 1MHz. TCK increased but > delay of 600us between transfers was still there. Time of MDW went down to 25 > seconds. > I suppose you really mean 600us, not 600ms. But related to this 600us how much time do you see activity. I suppose you have a full speed usb connection, so packets are send every 1ms or 1000us. So the relation activity to no activity is 400 to 600. This will not explain why it works so slow. > For comparison, I connected STM32 with the same setup. Communication with > STM32 is incomparably faster. Look below. I see the difference that PIC32 MDW > goes to some special function, unlike MDW on STM32. It seems to me, that > something inside mips_m4k_read_memory() works bad. Maybe a memory leak? Some > systems are not affected with it. But it looks that mine is. > > One thing confuses me. Why there is so small amount of debug messages for -d3 > ? This depends on the code, how many LOG_DEBUG's calls are there and when they are called. If all works ok there is no reason to report anything. > Debug: 352 35141 mips_m4k.c:785 mips_m4k_read_memory(): address: 0xa000, > size: 0x0004, count: 0x0400 > User : 410 64766 command.c:547 command_print(): 0xa000: 00078fdf > e37b95f3 9dbf515b cf54e881 95eb62e > 29625ms > ** STM32 > Debug: 442 42125 command.c:145 script_debug(): command - mdw ocd_mdw 0 1024 > User : 444 42203 command.c:547 command_print(): 0x: 20005000 080006c1 > 08000749 0800074d 08000751 08000755 08000759 000 78ms I suppose this STM32 has some debug monitor to make it so fast. I think the only way to see the reason of this slow behavior is to walk through the code and put some extra debug logs to see exactly where the problem is. I will try to help you. Thanks Salvador. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Fwd: Re: Status of PIC32/mips support?
On Thu, Apr 12, 2012 at 3:59 PM, Vaclav Peroutka wrote: >> >> Only for comparing, >> how much time takes it for this command: " (gdb) monitor mdw 0xa000 >> 1024 " ?. >> >> For me about 6 seconds (jtag at 350Khz real). >> > Hello, I just tried it on another computer - Windows XP again. Result is > approximately 30 seconds @ 200kHz real. I made a snapshot on oscilloscope (I > can send it here, too). I see that between JTAG transfers there are delays of > around 600us. I then experimentally increased TCK to 1MHz. TCK increased but > delay of 600us between transfers was still there. Time of MDW went down to 25 > seconds. 600 us plus time for the actual JTAG transfer sounds an awful lot like the 1 ms USB frame period. Perhaps the memory read function for MIPS executes the command queue after every word is transferred? Maybe simply because it's badly implemented, or maybe because the debug logic requires some polling or handshaking for each word. It's absolutely necessary for any sort of performance over high latency links such as USB to queue as many JTAG commands as possible before executing the queue. I have no insight into the MIPS code, but I remember from previous discussions that there's two different methods to access memory (pracc vs dma?). Maybe you're using the slow, polling, one? > For comparison, I connected STM32 with the same setup. Communication with > STM32 is incomparably faster. Look below. I see the difference that PIC32 MDW > goes to some special function, unlike MDW on STM32. It seems to me, that > something inside mips_m4k_read_memory() works bad. Maybe a memory leak? Some > systems are not affected with it. But it looks that mine is. Targets doesn't implement the mdw command directly. They implement a generic function to read memory, which the mdw command handler uses in turn. So the Cortex-M3 target has a corresponding read_memory-function. It probably just doesn't do a debug print. > One thing confuses me. Why there is so small amount of debug messages for -d3 > ? As I said, it depends on the target and interface code how much debug prints they do. There's a configure option to enable JTAG I/O debug which I think at least the ft2232 driver honours (beware of flooding though). You can also insert LOG_DEBUG():s yourself at appropriate places (i.e. in the driver where the queue is executed). Or you can try my new "ftdi" driver for FTx232 based adapters (in gerrit) that already prints a debug message when the queue is pushed to libusb. /Andreas -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] [PATCH]: 2e37930 ft2232: Support for Digilent HS1 USB adapter
Hello! On 11/04/2012 00:42, Andreas Fritiofson wrote: > Hi! > > Would you care to make and test a config file for my ftdi driver, > still in gerrit, in addition to the ft2232 patch? It should be > straight forward and very similar to configs for other adapters that > lack "extra" signals. The full patchset can be checked out (from > within an existing clone) with > git fetch http://openocd.zylin.com/p/openocd refs/changes/35/535/1&& > git checkout FETCH_HEAD > along with config files for all other ftdi based adapters (located in > the tcl/interface/ftdi/ subdirectory). Pass --enable-ftdi to configure > to enable the driver, which requires libusb-1.0. Sure, I will test that as soon as possible. Regards, Stéphane. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] openocd and the kwikstik k40
I am trying to use openocd with the Freescale kwikstik k40 (just the stick, without any tower). So far, I can connect to the k40, reset, halt, and read out flash addresses. Whenever I try to read a memory address, I get a "sticky" error. Googling the list archives gave vague hints about the jtag speed, but the 'adapter_khz 1' command just makes the error appear more slowly. Below I have a telnet session and the openocd output. Does anyone know how to get this working? Thanks, Richard richard@netboy:~$ telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > reset JTAG tap: k40.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) > halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x2100 pc: 0xc934 psp: 0x200012dc > mdw 0x0 16 0x: 20007ef0 0411 0eeb 0eeb 0eeb 0eeb 0eeb 0x0020: 0e49 0eeb 0e8f 0eeb > mdw 0x1800 16 JTAG-DP STICKY ERROR MEM_AP_CSW 0x2352, MEM_AP_TAR 0x1804 JTAG-DP STICKY ERROR MEM_AP_CSW 0x2352, MEM_AP_TAR 0x1804 Block read error address 0x1800 in procedure 'mdw' richard@netboy:~/git/openocd$ sudo ./src/openocd -s tcl -f board/kwikstik.cfg Open On-Chip Debugger 0.6.0-dev-00477-gf1c0133 (2012-03-30-12:02) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Warn : Adapter driver 'jlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' RCLK - adaptive trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain Info : add flash_bank kinetis k40.pflash Info : J-Link initialization started / target CPU reset initiated Info : J-Link Lite-FSL V1 compiled Jan 31 2011 11:00:51 Info : J-Link caps 0xb8ea7a3b Info : J-Link hw version 901 Info : J-Link hw type uknown 0x9 Info : J-Link max mem block 9096 Info : J-Link configuration Info : USB-Address: 0xff Info : Kickstart power on JTAG-pin 19: 0x Info : Vref = 3.63 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 Info : J-Link JTAG Interface ready Info : RCLK (adaptive clock speed) Info : JTAG tap: k40.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Info : k40.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from Info : JTAG tap: k40.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x2100 pc: 0xc934 psp: 0x200012dc -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Fwd: Re: Status of PIC32/mips support?
> > Only for comparing, > how much time takes it for this command: " (gdb) monitor mdw 0xa000 > 1024 " ?. > > For me about 6 seconds (jtag at 350Khz real). > Hello, I just tried it on another computer - Windows XP again. Result is approximately 30 seconds @ 200kHz real. I made a snapshot on oscilloscope (I can send it here, too). I see that between JTAG transfers there are delays of around 600us. I then experimentally increased TCK to 1MHz. TCK increased but delay of 600us between transfers was still there. Time of MDW went down to 25 seconds. For comparison, I connected STM32 with the same setup. Communication with STM32 is incomparably faster. Look below. I see the difference that PIC32 MDW goes to some special function, unlike MDW on STM32. It seems to me, that something inside mips_m4k_read_memory() works bad. Maybe a memory leak? Some systems are not affected with it. But it looks that mine is. One thing confuses me. Why there is so small amount of debug messages for -d3 ? Vaclav *** PIC32 Debug: 349 35141 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_mdw 0xa000 1024 Debug: 350 35141 command.c:145 script_debug(): command - mdw ocd_mdw 0xa000 1024 Debug: 352 35141 mips_m4k.c:785 mips_m4k_read_memory(): address: 0xa000, size: 0x0004, count: 0x0400 User : 410 64766 command.c:547 command_print(): 0xa000: 00078fdf e37b95f3 9dbf515b cf54e881 95eb62e 5 ** STM32 Debug: 442 42125 command.c:145 script_debug(): command - mdw ocd_mdw 0 1024 User : 444 42203 command.c:547 command_print(): 0x: 20005000 080006c1 08000749 0800074d 08000751 08000755 08000759 000 0 -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Debuging openocd
Hi, I try to setup a new developement environement on windows for compiling and debugging Openocd. I try to use the Eclipse with gdb to debug. So far I did this, ./configure --enable-maintainer-mode --build=i686-pc-cygwin --host=i686-pc-mingw32 --enable-ft2232_libftdi --disable-shared CFLAGS="-O0 -g -Wall -I/usr/local/include" LDFLAGS="-L/usr/local/lib" --disable-werror --enable-stlink To add debug information to openocd. If I test openocd without gdb it work well. But When I start it with gdb (thru eclipse) it got stuck at Debug: 153 953 transport.c:240 handle_transport_init(): handle_transport_init Debug: 154 953 stlink_transport.c:140 stlink_transport_init(): stlink_transport_init Debug: 155 953 stlink_transport.c:157 stlink_transport_init(): current transport stlink_swd Debug: 156 953 stlink_interface.c:41 stlink_interface_open(): stlink_interface_open Debug: 157 969 stlink_layout.c:43 stlink_layout_open(): stlink_layout_open Debug: 158 969 stlink_usb.c:1005 stlink_usb_open(): stlink_usb_open Debug: 159 969 stlink_usb.c:1020 stlink_usb_open(): transport: 1 vid: 0483 pid: 3748 What I'm missing ? $ i686-pc-mingw32-gcc --version i686-pc-mingw32-gcc (GCC) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc. $ gdb --version GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special) Eclipse Indigo Thanx for you help Jonathan -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
