|
From: Freddie C. <fre...@op...> - 2012-04-27 20:39:05
|
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! |