Programming Problem

I use a Lattice LFXP3C-3TN100C on a production board that has been made 
for several years with quantities in the thousands.  The HW-USBN-2A JTAG 
programmer typically works without complaint, both of them.  One is a 
Lattice unit and the other is a Chinese knockoff.

We are trying to finish a run of 600+ units and most have completed 
testing, but we have around 60 that can not be programmed.  We get an 
error that the device ID can't be verified.  The value returned is 
0xFFFFFFFE while the expected value is 0x01255043.  I would say there is 
a problem with a bad trace, but then I would expect *all* F's rather 
than just one bit being a zero.

I've traced the signals and they are getting where they belong.  Signals 
TDI and TMS are pulled up to 3.3 volts while TCK is not and only 
reaches 2.0 volts.  I can see transitions on TDI with pulses in the 
microsecond range.  This is the same with working boards.

These chips only need Vcc, PROG_N high and the four JTAG signals, TMS, 
TCK, TDO and TDI to be connected in order to program them.  We seem to 
have all that.

Any ideas on what to check?  The test fixture will program a good board 
just fine.  But these 60 units can't even pass chip ID verification.  I 
think I'm ready to replace the FPGA on one of them.

-- 

Rick C

Den onsdag den 23. november 2016 kl. 19.51.31 UTC+1 skrev rickman:
> I use a Lattice LFXP3C-3TN100C on a production board that has been made 
> for several years with quantities in the thousands.  The HW-USBN-2A JTAG 
> programmer typically works without complaint, both of them.  One is a 
> Lattice unit and the other is a Chinese knockoff.
> 
> We are trying to finish a run of 600+ units and most have completed 
> testing, but we have around 60 that can not be programmed.  We get an 
> error that the device ID can't be verified.  The value returned is 
> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there is 
> a problem with a bad trace, but then I would expect *all* F's rather 
> than just one bit being a zero.
> 
> I've traced the signals and they are getting where they belong.  Signals 
> TDI and TMS are pulled up to 3.3 volts while TCK is not and only 
> reaches 2.0 volts.  I can see transitions on TDI with pulses in the 
> microsecond range.  This is the same with working boards.
> 
> These chips only need Vcc, PROG_N high and the four JTAG signals, TMS, 
> TCK, TDO and TDI to be connected in order to program them.  We seem to 
> have all that.
> 
> Any ideas on what to check?  The test fixture will program a good board 
> just fine.  But these 60 units can't even pass chip ID verification.  I 
> think I'm ready to replace the FPGA on one of them.
> 

pull-down or series resistors of the wrong value?

On Wednesday, November 23, 2016 at 1:51:31 PM UTC-5, rickman wrote:
> I use a Lattice LFXP3C-3TN100C on a production board that has been made 
> for several years with quantities in the thousands.  The HW-USBN-2A JTAG 
> programmer typically works without complaint, both of them.  One is a 
> Lattice unit and the other is a Chinese knockoff.
> 
> We are trying to finish a run of 600+ units and most have completed 
> testing, but we have around 60 that can not be programmed.  We get an 
> error that the device ID can't be verified.  The value returned is 
> 0xFFFFFFFE while the expected value is 0x01255043.

The value 0xfffffffe is -2 in two's complement.  It might be indicating
an error code you can look up.

> I would say there is 
> a problem with a bad trace, but then I would expect *all* F's rather 
> than just one bit being a zero.
> 
> I've traced the signals and they are getting where they belong.  Signals 
> TDI and TMS are pulled up to 3.3 volts while TCK is not and only 
> reaches 2.0 volts.  I can see transitions on TDI with pulses in the 
> microsecond range.  This is the same with working boards.
> 
> These chips only need Vcc, PROG_N high and the four JTAG signals, TMS, 
> TCK, TDO and TDI to be connected in order to program them.  We seem to 
> have all that.
> 
> Any ideas on what to check?  The test fixture will program a good board 
> just fine.  But these 60 units can't even pass chip ID verification.  I 
> think I'm ready to replace the FPGA on one of them.

Best regards,
Rick C. Hodgin

On 11/23/2016 1:58 PM, lasselangwadtchristensen@gmail.com wrote:
> Den onsdag den 23. november 2016 kl. 19.51.31 UTC+1 skrev rickman:
>> I use a Lattice LFXP3C-3TN100C on a production board that has been made
>> for several years with quantities in the thousands.  The HW-USBN-2A JTAG
>> programmer typically works without complaint, both of them.  One is a
>> Lattice unit and the other is a Chinese knockoff.
>>
>> We are trying to finish a run of 600+ units and most have completed
>> testing, but we have around 60 that can not be programmed.  We get an
>> error that the device ID can't be verified.  The value returned is
>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there is
>> a problem with a bad trace, but then I would expect *all* F's rather
>> than just one bit being a zero.
>>
>> I've traced the signals and they are getting where they belong.  Signals
>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only
>> reaches 2.0 volts.  I can see transitions on TDI with pulses in the
>> microsecond range.  This is the same with working boards.
>>
>> These chips only need Vcc, PROG_N high and the four JTAG signals, TMS,
>> TCK, TDO and TDI to be connected in order to program them.  We seem to
>> have all that.
>>
>> Any ideas on what to check?  The test fixture will program a good board
>> just fine.  But these 60 units can't even pass chip ID verification.  I
>> think I'm ready to replace the FPGA on one of them.
>>
>
> pull-down or series resistors of the wrong value?

We have checked everything we can think of.  Even the one signal at 2.0 
volts works with many other boards... Maybe I'll have them add a pullup 
to that one signal.  Thanks for the idea.

-- 

Rick C

On Wed, 23 Nov 2016 13:51:30 -0500, rickman wrote:

> I use a Lattice LFXP3C-3TN100C on a production board that has been made
> for several years with quantities in the thousands.  The HW-USBN-2A JTAG
> programmer typically works without complaint, both of them.  One is a
> Lattice unit and the other is a Chinese knockoff.
> 
> We are trying to finish a run of 600+ units and most have completed
> testing, but we have around 60 that can not be programmed.  We get an
> error that the device ID can't be verified.  The value returned is
> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there is
> a problem with a bad trace, but then I would expect *all* F's rather
> than just one bit being a zero.
> 
> I've traced the signals and they are getting where they belong.  Signals
> TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches
> 2.0 volts.  I can see transitions on TDI with pulses in the microsecond
> range.  This is the same with working boards.
> 
> These chips only need Vcc, PROG_N high and the four JTAG signals, TMS,
> TCK, TDO and TDI to be connected in order to program them.  We seem to
> have all that.
> 
> Any ideas on what to check?  The test fixture will program a good board
> just fine.  But these 60 units can't even pass chip ID verification.  I
> think I'm ready to replace the FPGA on one of them.

Have you looked at the TDO line while the thing is ID-ing the chip?  Are 
you getting something that looks like 0x01255043 in there, or all ones?  
If you can get your hands on one good and some bad boards you should 
learn something.

An exponentially decaying high voltage might come across as 0xfffffffe, 
but I would expect that it would then sometimes come across as all 'f', 
or sometimes as 0xfffffffc, 0xfffffff8, etc.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Den onsdag den 23. november 2016 kl. 20.56.00 UTC+1 skrev Tim Wescott:
> On Wed, 23 Nov 2016 13:51:30 -0500, rickman wrote:
> 
> > I use a Lattice LFXP3C-3TN100C on a production board that has been made
> > for several years with quantities in the thousands.  The HW-USBN-2A JTAG
> > programmer typically works without complaint, both of them.  One is a
> > Lattice unit and the other is a Chinese knockoff.
> > 
> > We are trying to finish a run of 600+ units and most have completed
> > testing, but we have around 60 that can not be programmed.  We get an
> > error that the device ID can't be verified.  The value returned is
> > 0xFFFFFFFE while the expected value is 0x01255043.  I would say there is
> > a problem with a bad trace, but then I would expect *all* F's rather
> > than just one bit being a zero.
> > 
> > I've traced the signals and they are getting where they belong.  Signals
> > TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches
> > 2.0 volts.  I can see transitions on TDI with pulses in the microsecond
> > range.  This is the same with working boards.
> > 
> > These chips only need Vcc, PROG_N high and the four JTAG signals, TMS,
> > TCK, TDO and TDI to be connected in order to program them.  We seem to
> > have all that.
> > 
> > Any ideas on what to check?  The test fixture will program a good board
> > just fine.  But these 60 units can't even pass chip ID verification.  I
> > think I'm ready to replace the FPGA on one of them.
> 
> Have you looked at the TDO line while the thing is ID-ing the chip?  Are 
> you getting something that looks like 0x01255043 in there, or all ones?  
> If you can get your hands on one good and some bad boards you should 
> learn something.
> 
> An exponentially decaying high voltage might come across as 0xfffffffe, 
> but I would expect that it would then sometimes come across as all 'f', 
> or sometimes as 0xfffffffc, 0xfffffff8, etc.

or rising voltage if the data is sent LSB first

> We have checked everything we can think of.  Even the one signal at 2.0 
> volts works with many other boards... Maybe I'll have them add a pullup 
> to that one signal.  Thanks for the idea.
> 

Have you got the parts from a reliable source? I had a similar issue ("checked everything we can think of", failure rate about 20%) once. After weeks of searching in turned out that we have bought counterfeit parts... (It weren't FPGAs, however, but application processors...)

Thomas

www.entner-electronics.com - Home of EEBlaster and JPEG-Codec

On Wed, 23 Nov 2016 13:55:32 -0800, lasselangwadtchristensen wrote:

> Den onsdag den 23. november 2016 kl. 20.56.00 UTC+1 skrev Tim Wescott:
>> On Wed, 23 Nov 2016 13:51:30 -0500, rickman wrote:
>> 
>> > I use a Lattice LFXP3C-3TN100C on a production board that has been
>> > made for several years with quantities in the thousands.  The
>> > HW-USBN-2A JTAG programmer typically works without complaint, both of
>> > them.  One is a Lattice unit and the other is a Chinese knockoff.
>> > 
>> > We are trying to finish a run of 600+ units and most have completed
>> > testing, but we have around 60 that can not be programmed.  We get an
>> > error that the device ID can't be verified.  The value returned is
>> > 0xFFFFFFFE while the expected value is 0x01255043.  I would say there
>> > is a problem with a bad trace, but then I would expect *all* F's
>> > rather than just one bit being a zero.
>> > 
>> > I've traced the signals and they are getting where they belong. 
>> > Signals TDI and TMS are pulled up to 3.3 volts while TCK is not and
>> > only reaches 2.0 volts.  I can see transitions on TDI with pulses in
>> > the microsecond range.  This is the same with working boards.
>> > 
>> > These chips only need Vcc, PROG_N high and the four JTAG signals,
>> > TMS, TCK, TDO and TDI to be connected in order to program them.  We
>> > seem to have all that.
>> > 
>> > Any ideas on what to check?  The test fixture will program a good
>> > board just fine.  But these 60 units can't even pass chip ID
>> > verification.  I think I'm ready to replace the FPGA on one of them.
>> 
>> Have you looked at the TDO line while the thing is ID-ing the chip? 
>> Are you getting something that looks like 0x01255043 in there, or all
>> ones? If you can get your hands on one good and some bad boards you
>> should learn something.
>> 
>> An exponentially decaying high voltage might come across as 0xfffffffe,
>> but I would expect that it would then sometimes come across as all 'f',
>> or sometimes as 0xfffffffc, 0xfffffff8, etc.
> 
> or rising voltage if the data is sent LSB first

Then it would be much easier to believe a reliable 0 LSB with all ones 
following.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

On 11/23/2016 2:55 PM, Tim Wescott wrote:
> On Wed, 23 Nov 2016 13:51:30 -0500, rickman wrote:
>
>> I use a Lattice LFXP3C-3TN100C on a production board that has been made
>> for several years with quantities in the thousands.  The HW-USBN-2A JTAG
>> programmer typically works without complaint, both of them.  One is a
>> Lattice unit and the other is a Chinese knockoff.
>>
>> We are trying to finish a run of 600+ units and most have completed
>> testing, but we have around 60 that can not be programmed.  We get an
>> error that the device ID can't be verified.  The value returned is
>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there is
>> a problem with a bad trace, but then I would expect *all* F's rather
>> than just one bit being a zero.
>>
>> I've traced the signals and they are getting where they belong.  Signals
>> TDI and TMS are pulled up to 3.3 volts while TCK is not and only reaches
>> 2.0 volts.  I can see transitions on TDI with pulses in the microsecond
>> range.  This is the same with working boards.
>>
>> These chips only need Vcc, PROG_N high and the four JTAG signals, TMS,
>> TCK, TDO and TDI to be connected in order to program them.  We seem to
>> have all that.
>>
>> Any ideas on what to check?  The test fixture will program a good board
>> just fine.  But these 60 units can't even pass chip ID verification.  I
>> think I'm ready to replace the FPGA on one of them.
>
> Have you looked at the TDO line while the thing is ID-ing the chip?  Are
> you getting something that looks like 0x01255043 in there, or all ones?
> If you can get your hands on one good and some bad boards you should
> learn something.
>
> An exponentially decaying high voltage might come across as 0xfffffffe,
> but I would expect that it would then sometimes come across as all 'f',
> or sometimes as 0xfffffffc, 0xfffffff8, etc.

I may have gotten to the bottom of this... or at least below the knees. 
The results of probing with the scope were a bit inconsistent which may 
be from not controlling all the variables.  But the programmer has a 
debug mode where you can toggle or set any of the FPGA input lines and 
get a report of the one output line from the FPGA.  After likely chasing 
my tail for a while I realized the TDI line was not toggling when I 
expected it to.  When I pursued this I found that board has some sort of 
a short to Vcc on TDI of around 500 ohms.  The driver couldn't pull it 
down at all.

After all was said and done this seemed to be a problem on only a single 
board.  I was able to program and test successfully three more boards. 
Everyone was going home (factory folk work early hours) so I called it a 
day and asked them to retest all the failed boards.  I had been told 
some failed in programming and some failed the audio testing, so I 
expect we have some various issues which may or may not all be real.

This all is exacerbated by the fact that I spend a large hunk of my time 
some four hours from the contract manufacturer.  When in Maryland, I am 
only an hour away which isn't so bad.  But I'm typically only there on 
weekends now.  With any luck the testing will be completed without 
significant issues.

To Thomas, yes, I thought of the counterfeit issue and asked if they 
were buying from a reliable source, but I already knew the answer.  The 
FPGAs are EOLed and only available from Arrow now.  I have used some 
3000 parts since last year and watching the web site inventory numbers, 
it would appear I am the *only* remaining user of these parts, lol!  So 
I have no doubt they bought them from Arrow who had put in a large order 
when the EOL announcement came out and are now stuck with 78,000 
parts!!!  Funny that they seem to be raising the price rather than 
lowering it.

-- 

Rick C

On 11/23/2016 6:18 PM, Tim Wescott wrote:
> On Wed, 23 Nov 2016 13:55:32 -0800, lasselangwadtchristensen wrote:
>
>> Den onsdag den 23. november 2016 kl. 20.56.00 UTC+1 skrev Tim Wescott:
>>> On Wed, 23 Nov 2016 13:51:30 -0500, rickman wrote:
>>>
>>>> I use a Lattice LFXP3C-3TN100C on a production board that has been
>>>> made for several years with quantities in the thousands.  The
>>>> HW-USBN-2A JTAG programmer typically works without complaint, both of
>>>> them.  One is a Lattice unit and the other is a Chinese knockoff.
>>>>
>>>> We are trying to finish a run of 600+ units and most have completed
>>>> testing, but we have around 60 that can not be programmed.  We get an
>>>> error that the device ID can't be verified.  The value returned is
>>>> 0xFFFFFFFE while the expected value is 0x01255043.  I would say there
>>>> is a problem with a bad trace, but then I would expect *all* F's
>>>> rather than just one bit being a zero.
>>>>
>>>> I've traced the signals and they are getting where they belong.
>>>> Signals TDI and TMS are pulled up to 3.3 volts while TCK is not and
>>>> only reaches 2.0 volts.  I can see transitions on TDI with pulses in
>>>> the microsecond range.  This is the same with working boards.
>>>>
>>>> These chips only need Vcc, PROG_N high and the four JTAG signals,
>>>> TMS, TCK, TDO and TDI to be connected in order to program them.  We
>>>> seem to have all that.
>>>>
>>>> Any ideas on what to check?  The test fixture will program a good
>>>> board just fine.  But these 60 units can't even pass chip ID
>>>> verification.  I think I'm ready to replace the FPGA on one of them.
>>>
>>> Have you looked at the TDO line while the thing is ID-ing the chip?
>>> Are you getting something that looks like 0x01255043 in there, or all
>>> ones? If you can get your hands on one good and some bad boards you
>>> should learn something.
>>>
>>> An exponentially decaying high voltage might come across as 0xfffffffe,
>>> but I would expect that it would then sometimes come across as all 'f',
>>> or sometimes as 0xfffffffc, 0xfffffff8, etc.
>>
>> or rising voltage if the data is sent LSB first
>
> Then it would be much easier to believe a reliable 0 LSB with all ones
> following.

The one board that actually failed programming seems to have a low 
resistance between the TDI line and Vcc.  I assume the TDI line being 
held high results in this pattern.  I'd have to dig into the JTAG spec 
to see just what is happening, but as it is limited to this one board 
(so far) I think I can ignore it.

It's a shame this product is now EOL itself.  There are still plenty of 
FPGAs available (even though they are EOL'd) and the test process works 
pretty well most of the time.  But then that is life in the engineering 
game.  On to the next product!

-- 

Rick C