On Fri, Apr 27, 2012 at 10:38 PM, Freddie Chopin <[email protected]> wrote: > Hi! > > This post is about the new FTDI driver by Andreas Fritiofson, using > libusb-1.0.
Hi! First of all, thanks for testing! > 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)? In the debug log you should see mpsse_set_divisor printing the resulting FT2232 divisor value following a change of speed. Can you verify that it has the expected value? You should also get a message from mpsse_set_frequency about the desired and actual set frequency. The latter should match the divisor value if the calculation is correct. > 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 So something's a bit fishy even without the patches. Signal integrity problem? Regardless, it should never crash. > 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? STM32 is what I've tested the most and it's been solid. Unfortunately I have limited access to boards with other chips so I can't debug it myself right now. As always, a debug log is a necessity and, if possible, also a backtrace from the crash (run it in gdb and do "bt full" as said before). > 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). The interface (adapter) API for setting speed is rather messy, with the function that sets the speed taking the parameter in an abstract "division" unit, along with two functions for converting between that and the normal everyday frequency unit. OpenOCD blatantly assumes that all values returned (in "division" units) by the conversion function is possible to set. In other words, OpenOCD expects the interface driver to be able to enumerate all settable frequencies, which of course is not universally possible. It would have been cleaner and more generic to have a single function taking the desired frequency in Hz and returning the actual achievable frequency that was set. And indeed, that is how I designed the lower MPSSE layer, with the side effect that the FTDI driver doesn't know of any "division" unit and so has no way to tell the rest of OpenOCD which frequency it could actually set. > 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! Impressive gain but rather pathetic speed. Is it the flash or the algorithm that's slow for LPC17xx? > 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. Probably the flash limit, or very close to it. You should see much greater gains for dump_image and upload to RAM. /Andreas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
