Re: [OpenOCD-devel] Fwd: Re: Status of PIC32/mips support?
Hi Salvador, thank you for deep description, comments are below Take a look at http://openocd.sourceforge.net/doc/doxygen/html/index.html, but probably you know it already. I did not know that pages. /** Stupid libusb does not offer async writes nor does it allow access to its fd - so we need some hacks here. \internal */ That in maybe the reason why communication is so slow on MS Windows. It might be worth to somehow collect requests and send bigger packets through libusb. Or another idea - is it possible to try binary drivers from FTDI on Windows ? I mean, not to use libusb/libftdi at all. Then we can compare speed of MDW. This however does not solve the problem for other interfaces like jlink,etc... You have reported that the mdw...1024 now takes 25 or 30 seconds instead of the initial 180. I don't know the reason. Reason is that I just try the same on different PC (but again with Windows XP OS). I plan to try it on Linux, but no time for it so far. But can you now flash your chip with a working are defined? For me this mdw...1024 command takes 6.7 seconds, but for programming 4k of flash only 0.7. So i expect your adapter can do it in 3 or 4 seconds. If not, why not?. I did not try that again. I will do it and tell you. In the meantime, I analyzed JTAG debugger from PIC32 starter kit. It is really fast debugger. But it seems to me that all JTAG routines are implemented in the MCU connected to PC. So communication through USB is quite high-level. Vaclav -- 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
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 Wed, Apr 11, 2012 at 5:46 PM, Vaclav Peroutka vacla...@seznam.cz wrote:
UPDATE: I switched off the debugging (-d 2 parameter) and run it again.
PIC32
was programmed correctly. Programming of 6800Bytes took 5100 seconds! Can I
do
some profiling of OpenOCD ? There must be something wrong inside... I don't
know
if it is libusb driver or openocd itself...
I use -d3, to see as much as possible.
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).
It took about 3 minutes for me @ 200kHz TCK (set in CFG file). See below.
Unbelievable... What can we do ?
Vaclav
Debug: 447 41969 command.c:145 script_debug(): command - ocd_command
ocd_command type ocd_mdw 0xa000 1024
Debug: 448 41969 command.c:145 script_debug(): command - mdw ocd_mdw
0xa000 1024
Debug: 450 41985 mips_m4k.c:785 mips_m4k_read_memory(): address: 0xa000,
size: 0x0004, count: 0x0400
User : 821 233125 command.c:547 command_print(): 0xa000: 000256b9
e33b9ff3 9d9f515b cf54e841 9dca62
e5
User : 822 233141 command.c:547 command_print(): 0xa020: 612d4c30
dd391f9f 36b8cef6 51011c21 4e3dd5ba 58b28958 fd569f41 89d202
c0
User : 823 233157 command.c:547 command_print(): 0xa040: 1d272602
5794af40 247f5163 99524301 4a07aaba fc35d5bc f7f0237f a5d26e
df
Do the same with -d3 to hopefully see what's happening during the
three minutes. It depends on the target and interface driver how much
useful info it prints at highest debug level, but at -d2 you won't be
able to see anything.
/Andreas
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
