Greetings all,
In the past few days I have been trying to get my USB Blaster clone
(called "USB Blaster mini") to work with OpenOCD from the latest git
tree (762ca59dd5cbe70026234d549bb5f5ac1a05d5b4
<http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=tree;h=762ca59dd5cbe70026234d549bb5f5ac1a05d5b4;hb=45287bda76ace1f93b9e48ead7fed83c774258d1>).
I have found out that support for this dongle is broken in OpenOCD due
to a couple bugs in the OpenOCD usbblaster interface driver:
1. The USB Blaster clone does not use the original FT245 chip, and so
it tries to emulate its behavior.
As it turns out, the API call FT_GetLatencyTimer is not properly
emulated by the clone, and this makes OpenOCD abort. In reality, this
API call is not necessary, so I have removed this call.
2. The LED blink code that was added in commit
(24943498e611649a540d98406288dd6d4889851d) made the JTAG communication
unstable, see
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commitdiff;h=24943498e611649a540d98406288dd6d4889851d
. The USB Blaster dongle would properly detect the IDCODE, but would
later fail when trying to read/write the DPACC ARM JTAG registers. Not
surpringly, this is because the blink code resets the out_value, which
keeps track of the state of the JTAG pins.
In my tests, disabling or blinking the LED flag made JTAG communication
very unstable. This flag needs to be permanently enabled for proper
operation.
I have attached a patch to this email that fixes these problems, and
officially supports the USB Blaster clones.
Regards,
Domien Nowicki.
Thanks.
This problem is typically coming from the use of bad BIT BANG control on
a dedicated port :-( !
Laurent
http://www.amontec.com/jtagkey.shtml
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
