Re: [OpenOCD-devel] Fwd: Re: Status of PIC32/mips support?

[Andreas F. <and...@gm...>]

On Thu, Apr 12, 2012 at 3:59 PM, Vaclav Peroutka <vac...@se...> 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.

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