Mike-

I agree the drive and resulting ringing is excessive for a single DSP load. In our defense, during our 2010 design
phase we were (probably overly) concerned about the 3 nsec rise/fall time spec that TI gives in their C5510 "EMU_1"
advisory. If you read that, is sounds quite unforgiving (as Richard pointed out).

-Jeff

> Jeff and other experimenters,
>
> The signal picture reminded me of something not directly related to this
> situation. The pic looks like you were using TI's original clock buffer
> card or specs. The original board was designed for extreme loads and is
> too hot [IMO] for single targets. You might want a buffer card for lab
> experiments that has a milder driver - I do not care for the under/over
> shoot, especially when I am try to perform an experiment - it gives me
> the impression that I could be introducing a new variable into the equation.
>
> FYI-
> For a multiple board situation where some work and some do not [and the
> list of 'suspect signals is not too large], often a curve tracer will
> help with broken traces/solder joints on BGAs
>
> mikedunn
>
> On 9/23/2013 7:48 AM, Jeff Brower wrote:
>> Mike-
>>
>>> 1. Is the problem frequency sensitive?? 5,10, 15 Mhz??
>>> 2. I think that SDconfig has a diagnostic mode - does it fail in the
>>> same place??
>>> 3. Have you tried selecting a 55or AA pattern and scoped it?? [maybe
>>> that is the missing image??]
>>> 4. A bit hokey but have you tried 2 scope probes on TCLK?? for just a
>>> bit of extra capacitance
>>> 5. Do the failing units identify the IR length??
>> Yes I did try these variations and tests.
>>
>> On one of the modules I was able to intermittently pass JTAG scan test by varying (a lot) the temperature of the PCB
>> and/or applying pressure to the chip. It looks to me that somehow this batch of modules has been through extreme
>> temperature cycling and suffered at least some (and probably several) fractured solder joints. I will need to talk
>> to
>> the customer :-)
>>
>> Thanks everyone for your help.
>>
>> -Jeff
>>
>>> On 9/20/2013 1:55 PM, Jeff Brower wrote:
>>>> All-
>>>>
>>>> I'm posting this question here, the global knowledge source for TI
>>>> JTAG related issues :-)
>>>>
>>>> I have a batch of C5510A modules that are showing inconsistent JTAG
>>>> scan test results. Out of 6, 3 are passing, two
>>>> with buffered TCK and RTCK, and 1 without (without = bypass the buffer
>>>> using zero-ohm Rs). The failing modules also
>>>> are configured both ways. Due to this variation, I'm concerned that
>>>> TCK/RTCK isn't the actual problem.
>>>>
>>>> My question is how can I verify that JTAG is "trying to work", and
>>>> thus it might be TCK related? SDConfig doesn't
>>>> allow this. Is there another utility? Below are some additional notes.
>>>> Thanks.
>>>>
>>>> -Jeff
>>>>
>>>> 1) Trace length from JTAG header to C5510A is less than 1".
>>>>
>>>> 2) Using dig scope, C5510 clocks are verified (27 MHz). /RESET timing
>>>> has been verified. Power sequence has been
>>>> verified. Silicon revision is 2.2, so RST_MODE is ignored.
>>>>
>>>> 3) I can post any scope trace required. A scope capture for the
>>>> buffered version is here:
>>>>
>>>> http://signalogic.com/images/Signalogic_C5510_TCK_b4_after_buffer.jpg
>>>>
>>>> 4) Emulator is an XDS510-Plus.
>
>
>
> _____________________________________
>

_____________________________________

Jeff and other experimenters,

The signal picture reminded me of something not directly related to this
situation. The pic looks like you were using TI's original clock buffer
card or specs. The original board was designed for extreme loads and is
too hot [IMO] for single targets. You might want a buffer card for lab
experiments that has a milder driver - I do not care for the under/over
shoot, especially when I am try to perform an experiment - it gives me
the impression that I could be introducing a new variable into the equation.

FYI-
For a multiple board situation where some work and some do not [and the
list of 'suspect signals is not too large], often a curve tracer will
help with broken traces/solder joints on BGAs

mikedunn

On 9/23/2013 7:48 AM, Jeff Brower wrote:
> Mike-
>
>> 1. Is the problem frequency sensitive?? 5,10, 15 Mhz??
>> 2. I think that SDconfig has a diagnostic mode - does it fail in the
>> same place??
>> 3. Have you tried selecting a 55or AA pattern and scoped it?? [maybe
>> that is the missing image??]
>> 4. A bit hokey but have you tried 2 scope probes on TCLK?? for just a
>> bit of extra capacitance
>> 5. Do the failing units identify the IR length??
> Yes I did try these variations and tests.
>
> On one of the modules I was able to intermittently pass JTAG scan test by varying (a lot) the temperature of the PCB
> and/or applying pressure to the chip. It looks to me that somehow this batch of modules has been through extreme
> temperature cycling and suffered at least some (and probably several) fractured solder joints. I will need to talk to
> the customer :-)
>
> Thanks everyone for your help.
>
> -Jeff
>
>> On 9/20/2013 1:55 PM, Jeff Brower wrote:
>>> All-
>>>
>>> I'm posting this question here, the global knowledge source for TI
>>> JTAG related issues :-)
>>>
>>> I have a batch of C5510A modules that are showing inconsistent JTAG
>>> scan test results. Out of 6, 3 are passing, two
>>> with buffered TCK and RTCK, and 1 without (without = bypass the buffer
>>> using zero-ohm Rs). The failing modules also
>>> are configured both ways. Due to this variation, I'm concerned that
>>> TCK/RTCK isn't the actual problem.
>>>
>>> My question is how can I verify that JTAG is "trying to work", and
>>> thus it might be TCK related? SDConfig doesn't
>>> allow this. Is there another utility? Below are some additional notes.
>>> Thanks.
>>>
>>> -Jeff
>>>
>>> 1) Trace length from JTAG header to C5510A is less than 1".
>>>
>>> 2) Using dig scope, C5510 clocks are verified (27 MHz). /RESET timing
>>> has been verified. Power sequence has been
>>> verified. Silicon revision is 2.2, so RST_MODE is ignored.
>>>
>>> 3) I can post any scope trace required. A scope capture for the
>>> buffered version is here:
>>>
>>> http://signalogic.com/images/Signalogic_C5510_TCK_b4_after_buffer.jpg
>>>
>>> 4) Emulator is an XDS510-Plus.

_____________________________________

Richard-

Thanks for your reply. The last one, "in the board", was a good guess.

The second one ("knee" glitch in TCK signal) we wrestled with during initial
development of this module 3 years ago. The image in my original post shows an
example of this before and after.

-Jeff

Richard Williams wrote:

> Jeff,
>
> This link may help:
> You probably want to read:
> Advisary EMU_1
>
> and since the root of the problem is probably in the board the DSP is mounted
> to, this link may help:
> R. Williams
>
> ---------- Original Message -----------
> From: "Jeff Brower"
> To: c..., c...
> Sent: Fri, 20 Sep 2013 13:55:02 -0500 (CDT)
> Subject: [c6x] TI JTAG signal integrity issue
>
> > All-
> >
> > I'm posting this question here, the global knowledge source for TI
> > JTAG related issues :-)
> >
> > I have a batch of C5510A modules that are showing inconsistent JTAG
> > scan test results. Out of 6, 3 are passing, two with buffered TCK and
> > RTCK, and 1 without (without = bypass the buffer using zero-ohm Rs).
> > The failing modules also are configured both ways. Due to this
> > variation, I'm concerned that TCK/RTCK isn't the actual problem.
> >
> > My question is how can I verify that JTAG is "trying to work", and
> > thus it might be TCK related? SDConfig doesn't allow this. Is there
> > another utility? Below are some additional notes. Thanks.
> >
> > -Jeff
> >
> > 1) Trace length from JTAG header to C5510A is less than 1".
> >
> > 2) Using dig scope, C5510 clocks are verified (27 MHz). /RESET timing
> > has been verified. Power sequence has been verified. Silicon
> > revision is 2.2, so RST_MODE is ignored.
> >
> > 3) I can post any scope trace required. A scope capture for the
> > buffered version is here:
> >
> > http://signalogic.com/images/Signalogic_C5510_TCK_b4_after_buffer.jpg
> >
> > 4) Emulator is an XDS510-Plus.
> ------- End of Original Message -------

Mike-

> 1. Is the problem frequency sensitive?? 5,10, 15 Mhz??
> 2. I think that SDconfig has a diagnostic mode - does it fail in the
> same place??
> 3. Have you tried selecting a 55or AA pattern and scoped it?? [maybe
> that is the missing image??]
> 4. A bit hokey but have you tried 2 scope probes on TCLK?? for just a
> bit of extra capacitance
> 5. Do the failing units identify the IR length??

Yes I did try these variations and tests.

On one of the modules I was able to intermittently pass JTAG scan test by varying (a lot) the temperature of the PCB
and/or applying pressure to the chip. It looks to me that somehow this batch of modules has been through extreme
temperature cycling and suffered at least some (and probably several) fractured solder joints. I will need to talk to
the customer :-)

Thanks everyone for your help.

-Jeff

> On 9/20/2013 1:55 PM, Jeff Brower wrote:
>>
>> All-
>>
>> I'm posting this question here, the global knowledge source for TI
>> JTAG related issues :-)
>>
>> I have a batch of C5510A modules that are showing inconsistent JTAG
>> scan test results. Out of 6, 3 are passing, two
>> with buffered TCK and RTCK, and 1 without (without = bypass the buffer
>> using zero-ohm Rs). The failing modules also
>> are configured both ways. Due to this variation, I'm concerned that
>> TCK/RTCK isn't the actual problem.
>>
>> My question is how can I verify that JTAG is "trying to work", and
>> thus it might be TCK related? SDConfig doesn't
>> allow this. Is there another utility? Below are some additional notes.
>> Thanks.
>>
>> -Jeff
>>
>> 1) Trace length from JTAG header to C5510A is less than 1".
>>
>> 2) Using dig scope, C5510 clocks are verified (27 MHz). /RESET timing
>> has been verified. Power sequence has been
>> verified. Silicon revision is 2.2, so RST_MODE is ignored.
>>
>> 3) I can post any scope trace required. A scope capture for the
>> buffered version is here:
>>
>> http://signalogic.com/images/Signalogic_C5510_TCK_b4_after_buffer.jpg
>>
>> 4) Emulator is an XDS510-Plus.

_____________________________________

Carlos-

Thanks, all things verifed that you mention, except for opens, which I can't look under the C5510A BGA.

-Jeff

> I have used jtag for 10 year+ and very reliable. So I would check for obvious. Is it correct voltage level? Also
> jtag has simple primitives (depends on your app) that allow simple test of the chain and read s dsp ID. While this is
> happening look at clk , mode, data in n out. Data show be lvttl n fast rise n fall time in nS. Verify u do not have
> opens, or noise on signal or superimposed clks or data. It show be very clean. Hope this helps.
>
> Sent from Yahoo! Mail on Android

_____________________________________

Hello Jeff,

1. Is the problem frequency sensitive?? 5,10, 15 Mhz??
2. I think that SDconfig has a diagnostic mode - does it fail in the
same place??
3. Have you tried selecting a 55or AA pattern and scoped it?? [maybe
that is the missing image??]
4. A bit hokey but have you tried 2 scope probes on TCLK?? for just a
bit of extra capacitance
5. Do the failing units identify the IR length??

mikedunn

On 9/20/2013 1:55 PM, Jeff Brower wrote:
>
> All-
>
> I'm posting this question here, the global knowledge source for TI
> JTAG related issues :-)
>
> I have a batch of C5510A modules that are showing inconsistent JTAG
> scan test results. Out of 6, 3 are passing, two
> with buffered TCK and RTCK, and 1 without (without = bypass the buffer
> using zero-ohm Rs). The failing modules also
> are configured both ways. Due to this variation, I'm concerned that
> TCK/RTCK isn't the actual problem.
>
> My question is how can I verify that JTAG is "trying to work", and
> thus it might be TCK related? SDConfig doesn't
> allow this. Is there another utility? Below are some additional notes.
> Thanks.
>
> -Jeff
>
> 1) Trace length from JTAG header to C5510A is less than 1".
>
> 2) Using dig scope, C5510 clocks are verified (27 MHz). /RESET timing
> has been verified. Power sequence has been
> verified. Silicon revision is 2.2, so RST_MODE is ignored.
>
> 3) I can post any scope trace required. A scope capture for the
> buffered version is here:
>
> http://signalogic.com/images/Signalogic_C5510_TCK_b4_after_buffer.jpg
>
> 4) Emulator is an XDS510-Plus.

Carlos-

> Is this the only jtag device on the chain? If so u have 5
> lines to worry about. TDo. TDI. TCK TRST and TMS and
> od course gnd.

Thanks. Yes only one C5510 in the chain. Yes I know it could be other JTAG signals, but how to determine what part
of JTAG failed? Did any part succeed? Are any scan bits correct? I need something more than all-or-nothing test.

-Jeff

_____________________________________

Jeff,

This link may help:

You probably want to read:
Advisary EMU_1

and since the root of the problem is probably in the board the DSP is mounted
to, this link may help:

R. Williams

---------- Original Message -----------
From: "Jeff Brower"
To: c..., c...
Sent: Fri, 20 Sep 2013 13:55:02 -0500 (CDT)
Subject: [c6x] TI JTAG signal integrity issue

> All-
>
> I'm posting this question here, the global knowledge source for TI
> JTAG related issues :-)
>
> I have a batch of C5510A modules that are showing inconsistent JTAG
> scan test results. Out of 6, 3 are passing, two with buffered TCK and
> RTCK, and 1 without (without = bypass the buffer using zero-ohm Rs).
> The failing modules also are configured both ways. Due to this
> variation, I'm concerned that TCK/RTCK isn't the actual problem.
>
> My question is how can I verify that JTAG is "trying to work", and
> thus it might be TCK related? SDConfig doesn't allow this. Is there
> another utility? Below are some additional notes. Thanks.
>
> -Jeff
>
> 1) Trace length from JTAG header to C5510A is less than 1".
>
> 2) Using dig scope, C5510 clocks are verified (27 MHz). /RESET timing
> has been verified. Power sequence has been verified. Silicon
> revision is 2.2, so RST_MODE is ignored.
>
> 3) I can post any scope trace required. A scope capture for the
> buffered version is here:
>
> http://signalogic.com/images/Signalogic_C5510_TCK_b4_after_buffer.jpg
>
> 4) Emulator is an XDS510-Plus.
------- End of Original Message -------

_____________________________________

All-

I'm posting this question here, the global knowledge source for TI JTAG related issues :-)

I have a batch of C5510A modules that are showing inconsistent JTAG scan test results. Out of 6, 3 are passing, two
with buffered TCK and RTCK, and 1 without (without = bypass the buffer using zero-ohm Rs). The failing modules also
are configured both ways. Due to this variation, I'm concerned that TCK/RTCK isn't the actual problem.

My question is how can I verify that JTAG is "trying to work", and thus it might be TCK related? SDConfig doesn't
allow this. Is there another utility? Below are some additional notes. Thanks.

-Jeff

1) Trace length from JTAG header to C5510A is less than 1".

2) Using dig scope, C5510 clocks are verified (27 MHz). /RESET timing has been verified. Power sequence has been
verified. Silicon revision is 2.2, so RST_MODE is ignored.

3) I can post any scope trace required. A scope capture for the buffered version is here:

http://signalogic.com/images/Signalogic_C5510_TCK_b4_after_buffer.jpg

4) Emulator is an XDS510-Plus.

_____________________________________