[OpenOCD-devel] FTDI driver by Andreas Fritiofson

[Freddie C. <fre...@op...>]

Hi!

This post is about the new FTDI driver by Andreas Fritiofson, using 
libusb-1.0.

I've managed to compile that code with libusbx-1.0.10 for Windows. I've 
installed driver and most of the features work, but there are some 
problems - as usual (;

I start OpenOCD like this:
 > openocd -f interface/ftdi/jtagkey.cfg -f target/lpc1768.cfg -c 
"reset_config trst_and_srst; adapter_khz 500"

I connect with telnet and do the following:
>> reset init
> JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ve
> r: 0x4)
> target state: halted
> target halted due to debug-request, current mode: Thread
> xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
>> resume

The prompt "hangs" (no response, no new line to enter some new command, 
nothing), target resumes, OpenOCD crashes in about 5-10 seconds.

You would expect it to be related to "reset_config", but... it is 
related to "adapter_khz" - omitting the speed change makes this command 
work OK, but OpenOCD itself (and debugging via GDB) is excruciatingly 
slow...

Maybe there is some problem with speed calculations (like specifying 
"500" results in "2000" or sth like that)?

By "trial and error" I've found the highest speed that does not crush 
OpenOCD to be 399kHz, setting 400kHz does not work. The target after 
reset uses 4MHz internal oscillator.

On "normal OpenOCD" with libusb-win32 it does not crush, but for speeds 
over and including 333kHz "resume" command gives:
>> resume
> Invalid ACK 0x7 in JTAG-DP transaction

Another funny thing is that some other commands work fine - for example 
I can flash and debug the target at 500, but only "flash and debug" - I 
cannot debug a firmware that was flashed in a previous session (GDB says 
some strange things, OpenOCD crashes after 5-10s)

Trying to recreate that behavior for STM32 did not work - "resume" 
command works for adapter_khz up to 1333, which is a limit for 8MHz 
core... (I even tried 1600, which is too much, and no problems with 
resume...)

Any ideas?

One minor issue - "normal" libftdi driver returns "real" speed after 
adapter_khz command (you request 399, it returns 400kHz, you request 
129, it returns 127), the ftdi driver returns what it received (no 
recalculation).

Flashing about 400kB to LPC1769 at 4MHz (JTAG at 399kHz) via GDB - 
9kB/s, using "normal OpenOCD" with libusb-win32 - 4kB/s, so the gain is 
pretty impresive!

Similar test for STM32, ~120kB upload, core @ 8MHz, JTAG @ 1MHz - 31kB/s 
vs. 29kB/s, not so impressive, but that may be the limit of the flash 
memory.

As usual - I can provide binaries to anyone willing to test on Windows.

Regards!