On 06/28/2011 09:19 AM, Domien Nowicki wrote:
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.
Does the failure happen with an original USB Blaster, or only with the
clone?
I don't see how toggling the LED could cause these kind of problems - I
would like to see an explanation *why* this causes the failure, before I
believe the patch fixes the root cause of the problem.
cu
Michael
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
