On 04/12/2012 03:59 PM, Vaclav Peroutka wrote: >> Only for comparing, >> how much time takes it for this command: " (gdb) monitor mdw 0xa0000000 >> 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: 0xa0000000, > size: 0x00000004, count: 0x00000400 > User : 410 64766 command.c:547 command_print(): 0xa0000000: 00078fdf 00000000 > 00000000 00000000 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(): 0x00000000: 20005000 080006c1 > 08000749 0800074d 08000751 08000755 08000759 0000000 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 [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
