On 1/07/2011 8:47 PM, Spencer Oliver wrote:
On 1 July 2011 00:41, Andrew Leech<[email protected]> wrote:
Only problem is, it's incredibly slow, unusably slow. A single step can take
5 seconds, where on a normal tcp connection with same configs feels close to
instant, so maybe about 1/4 of a second. Did your windows one behave better?
If so, do you know what version/release of gdb you used?
used Sourcery G++ Lite 2011.03-42
Have not noticed any speed issues, most of my testing was under linux however.
I am running winxp, that has always proved fairly nippy compared to
vista anyway.
Thanks, I was on 2010q3. Tried the newer one, and it initially didn't
work, just locked up like yagarto. I eventually found reducing the
jtag_nsrst_delay and jtag_ntrst_delay in my config and that got the
newer Sourcery going (although this doesn't get yagarto going, it still
doesn't work for me).
Stepping is still slow though. I'm wondering if this is related to my
cygwin on this machine, I've noticed that configure scripts on anything
run incredibly slowly, never found out why. I decided to cross compile
openocd from linux to rule out any issues from compiling with my cygwin
(even though I used the mno-cygwin flag) but this also didn't make any
difference. I'm not sure, maybe cygwin is stuffing up port's still or
something.
Delving into openocd logs, taking a -d3 on both pipe and tcp usage, I
get exactly the same commands being run for both when stepping over the
first line of my program, but in pipe usage lots of them take 100ms longer:
pipe:
Debug: 1292 17869 arm7_9_common.c:2121 arm7_9_step():
target stepped
Debug: 1293 17969 gdb_server.c:2200 gdb_input_inner():
received packet: 'g'
Debug: 1294 18078 gdb_server.c:2200 gdb_input_inner():
received packet: 's'
Debug: 1295 18078 target.c:1063
target_call_event_callbacks(): target event 7 (gdb-start)
tcp:
Debug: 1161 36347 0 arm7_9_common.c:2121
arm7_9_step(): target stepped
Debug: 1162 36347 0 gdb_server.c:2200
gdb_input_inner(): received packet: 'g'
Debug: 1163 36348 1 gdb_server.c:2200
gdb_input_inner(): received packet: 's'
Debug: 1164 36349 1 target.c:1063
target_call_event_callbacks(): target event 7 (gdb-start)
notice the time counter increments 100 ms after both the arm7... line
and the first received packet, whereas for tcp usage there's increments
of 0 and 1 ms.
There's heaps of commands in the pipe usage that have this extra 100ms
delay in them:
Debug: 1364 18111 target.c:1063
target_call_event_callbacks(): target event 8 (gdb-end)
Debug: 1365 18111 arm7_9_common.c:2121
arm7_9_step(): target stepped
here-> Debug: 1366 18211 gdb_server.c:2200
gdb_input_inner(): received packet: 'g'
here-> Debug: 1367 18318 gdb_server.c:2200
gdb_input_inner(): received packet: "'m1102941c,4'"
Debug: 1368 18318 gdb_server.c:1278
gdb_read_memory_packet(): addr: "0x1102941c," len: 0x00000004
Debug: 1369 18318 target.c:1444
target_read_buffer(): reading buffer of 4 byte at
0x1102941c
Debug: 1370 18318 arm7_9_common.c:2270
arm7_9_read_memory(): address: "0x1102941c," size:
"0x00000004," count: 0x00000001
here-> Debug: 1371 18419 gdb_server.c:2200
gdb_input_inner(): received packet: "'m110294ac,4'"
after most, but not all arm7_9_read_memory commands, here one that didn't:
Debug: 1297 18078 gdb_server.c:1475
gdb_step_continue_packet(): step
Debug: 1225 17838 arm7_9_common.c:2270
arm7_9_read_memory(): address: "0x110294a4," size:
"0x00000004," count: 0x00000001
Debug: 1226 17839 target.c:1606 target_read_u32():
address: "0x110294a4," value: 0xe3a01004
Debug: 1227 17839 arm7_9_common.c:1615
arm7_9_restore_context(): -
Debug: 1228 17849 arm7_9_common.c:1638
arm7_9_restore_context(): examining Supervisor mode
As far as I can tell, every arm7_9_read_memory() call after a
target_read_buffer() has the 100ms delay (it's always between 100 and
103ms) added to it, and there's plenty of them. I'm guessing that's when
openocd is transferring the read data back up the pipe?
This might be a far too obscure issue to find, and I don't have another
computer to try it on at the moment to find out if it's something
specific to my particular pc, or a broader issue. For what it's worth
I'm on Win 7 x64, using openocd with proprietary ftdi driver.
Just had an idea, and now I definitely think it's a system wide pipe
issue; from cygwin prompt:
$ time echo "blah"
blah
real 0m0.001s
user 0m0.000s
sys 0m0.000s
$ time echo "blah" | cat
blah
real 0m0.151s
user 0m0.031s
sys 0m0.030s
Darn, might have to hit up the cygwin guys for help.
One other point, do you know whether you can get openocd to add it's own
program directory to the search path for the source [find ...] lines? It'd
be great to only need the openocd.cfg file in the eclipse project dir, and
have it reference the interface and target files from the common openocd
folder. Otherwise I'll likely copy the contents of the files into my
openocd.cfg rather than have a copy of target and interface folders in all
my project folders.
try something like:
add_script_search_dir {c:\cygwin\home\soliver\openocd\openocd\tcl}
Thanks for that, that's exactly what I was looking for.
Cheers,
Andrew
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
