Re: [Openocd-development] USB Blaster support broken

[Andreas Fritiofson]

On Tue, Jun 28, 2011 at 9:19 AM, Domien Nowicki wrote:

> **
> 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.
>

Are you sure this is not the bug in FTD2XX on Linux that was mentioned on
this list recently? In that case, libftdi shouldn't be affected so it could
be left as-is. For ft2232 the error was changed to a warning as a workaround
(if that patch got merged), perhaps do the same here?

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.
>

Do you have a clue as to WHY the LED signal must be set for the dongle to
function properly? I don't know the internals of the USB Blaster in detail,
but it doesn't sound right. For sure, all our USB Blasters blink when used
with the Altera tools. No problem there.

If out_value keeps state, the blink function is obviously broken, but I
don't see why it couldn't be fixed by modifying only the LED bit in
out_value.

Also, why have you added commented out code? If it doesn't work (it
doesn't), don't add it. Of course the better solution would be to make it
work. (Hint: fix the bit clear, should be ~LED.)

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] USB Blaster support broken

[Michael Schwingen]

On 06/28/2011 09:34 AM, Laurent Gauch 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 
). 



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 :-( !

Please don't troll.

Looking at the patch, the LED handling seems to be integrated with the 
lowlevel code just fine - there is no bypassing of lower layers to 
access the LED, rather, the LED bit is handled at the same place as the 
other JTAG signals.


cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] USB Blaster support broken

[Michael Schwingen]

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 
).


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

Re: [Openocd-development] USB Blaster support broken

[Øyvind Harboe]

Please see if you can get someone to review the changes and
when it is ready, resubmit the patch as a git patch.

http://repo.or.cz/w/openocd.git/blob/HEAD:/HACKING

Thanks!


-- 
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] USB Blaster support broken

[Laurent Gauch]

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 
).


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