Programming Problem

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

--

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?

 

[Rick C. Hodgin]

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

 

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

 

[rickman]

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

 

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

--

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

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

 

[Tim Wescott]

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!

 

[rickman]

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

 

[rickman]

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

 

[rickman]

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.

BTW, thanks to everyone for the suggestions.

--

Rick C

 

[Les Cargill]

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.

All F's indicate a level problem on the data line(s) to me. Check
termination and levels - or watch it with a very high Z scope if you
can get the triggering right.

Adding a scope Heisenbergs the circuit but that may offer inspiration
in solutions.

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.

Are these inherently 3 volt parts? If not, ithe corcuit is overterminated.

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.

--
Les Cargill

 

[rickman]

On 11/27/2016 1:57 PM, Les Cargill wrote:

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.



All F's indicate a level problem on the data line(s) to me. Check
termination and levels - or watch it with a very high Z scope if you
can get the triggering right.

The return data wasn't all 1s. It was all 1s other than a single bit
which was zero. All ones can have multiple problems. The output is
one. TCK not getting to the chip is another.

Funny thing... I did a Google search on 0xFFFFFFFE and found my own
reply to someone else having a similar problem. In the end he simply
had an unknown connection issue which cleared up while fiddling with it
all. Seems the 0xFFFFFFFE result is a common problem when the cabling
is not right. In this case it was the TDI signal.

Adding a scope Heisenbergs the circuit but that may offer inspiration
in solutions.

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.


Are these inherently 3 volt parts? If not, ithe corcuit is overterminated.

Not sure what you intended to say here. But I forgot to mention that
another issue that confused the debug was a difference between the
Lattice programming adapter and the Chinese device I bought a while back
and has been working ok. Seems the Chinese programmer only pulls the
outputs to around 2 volts leaving no voltage margin in the worst case.
I only see this on one signal as the others are pulled high. TCK is
pulled low as recommended by some reference I encountered a long time
ago. This prevents the single rising edge that would be detected on
power up. A 4.7K resistor shouldn't be a problem for any decent device,
but obviously chip in the Chinese programmer isn't a "decent device".

So seeing the 2 volt Vhi on just one pin made me look at the test board
to see what was holding it low. lol


--

Rick C

 

[Les Cargill]

rickman wrote:

On 11/27/2016 1:57 PM, Les Cargill wrote:
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.



All F's indicate a level problem on the data line(s) to me. Check
termination and levels - or watch it with a very high Z scope if you
can get the triggering right.

The return data wasn't all 1s. It was all 1s other than a single bit
which was zero. All ones can have multiple problems. The output is
one. TCK not getting to the chip is another.

Sorry; my visual cortex returned all 1s for the 0xFFFFFFFE ....

Funny thing... I did a Google search on 0xFFFFFFFE and found my own
reply to someone else having a similar problem. In the end he simply
had an unknown connection issue which cleared up while fiddling with it
all. Seems the 0xFFFFFFFE result is a common problem when the cabling
is not right. In this case it was the TDI signal.

That's a scream.

Woohoo! Fixed.

Adding a scope Heisenbergs the circuit but that may offer inspiration
in solutions.

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.


Are these inherently 3 volt parts? If not, ithe corcuit is
overterminated.

Not sure what you intended to say here.

R(termination) too low. Not enough current, IOW...

But I forgot to mention that
another issue that confused the debug was a difference between the
Lattice programming adapter and the Chinese device I bought a while back
and has been working ok. Seems the Chinese programmer only pulls the
outputs to around 2 volts leaving no voltage margin in the worst case. I
only see this on one signal as the others are pulled high. TCK is
pulled low as recommended by some reference I encountered a long time
ago. This prevents the single rising edge that would be detected on
power up. A 4.7K resistor shouldn't be a problem for any decent device,
but obviously chip in the Chinese programmer isn't a "decent device".

Yuck.

So seeing the 2 volt Vhi on just one pin made me look at the test board
to see what was holding it low. lol

--
Les Cargill

 

[GaborSzakacs]

rickman wrote:

On 11/27/2016 1:57 PM, Les Cargill wrote:
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.



All F's indicate a level problem on the data line(s) to me. Check
termination and levels - or watch it with a very high Z scope if you
can get the triggering right.

The return data wasn't all 1s. It was all 1s other than a single bit
which was zero. All ones can have multiple problems. The output is
one. TCK not getting to the chip is another.

Funny thing... I did a Google search on 0xFFFFFFFE and found my own
reply to someone else having a similar problem. In the end he simply
had an unknown connection issue which cleared up while fiddling with it
all. Seems the 0xFFFFFFFE result is a common problem when the cabling
is not right. In this case it was the TDI signal.


Adding a scope Heisenbergs the circuit but that may offer inspiration
in solutions.

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.


Are these inherently 3 volt parts? If not, ithe corcuit is
overterminated.

Not sure what you intended to say here. But I forgot to mention that
another issue that confused the debug was a difference between the
Lattice programming adapter and the Chinese device I bought a while back
and has been working ok. Seems the Chinese programmer only pulls the
outputs to around 2 volts leaving no voltage margin in the worst case. I
only see this on one signal as the others are pulled high. TCK is
pulled low as recommended by some reference I encountered a long time
ago. This prevents the single rising edge that would be detected on
power up. A 4.7K resistor shouldn't be a problem for any decent device,
but obviously chip in the Chinese programmer isn't a "decent device".

So seeing the 2 volt Vhi on just one pin made me look at the test board
to see what was holding it low. lol

Maybe the Chinese programmer uses an open-drain output with a pull-up
to Vref rather than powering an active driver with Vref? It would be
very strange for an active driver to limit its output to 2V with only
4.7K pulling down (426uA nominal).

--
Gabor

 

[rickman]

On 11/29/2016 9:01 AM, GaborSzakacs wrote:

rickman wrote:
On 11/27/2016 1:57 PM, Les Cargill wrote:
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.



All F's indicate a level problem on the data line(s) to me. Check
termination and levels - or watch it with a very high Z scope if you
can get the triggering right.

The return data wasn't all 1s. It was all 1s other than a single bit
which was zero. All ones can have multiple problems. The output is
one. TCK not getting to the chip is another.

Funny thing... I did a Google search on 0xFFFFFFFE and found my own
reply to someone else having a similar problem. In the end he simply
had an unknown connection issue which cleared up while fiddling with
it all. Seems the 0xFFFFFFFE result is a common problem when the
cabling is not right. In this case it was the TDI signal.


Adding a scope Heisenbergs the circuit but that may offer inspiration
in solutions.

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.


Are these inherently 3 volt parts? If not, ithe corcuit is
overterminated.

Not sure what you intended to say here. But I forgot to mention that
another issue that confused the debug was a difference between the
Lattice programming adapter and the Chinese device I bought a while
back and has been working ok. Seems the Chinese programmer only pulls
the outputs to around 2 volts leaving no voltage margin in the worst
case. I only see this on one signal as the others are pulled high.
TCK is pulled low as recommended by some reference I encountered a
long time ago. This prevents the single rising edge that would be
detected on power up. A 4.7K resistor shouldn't be a problem for any
decent device, but obviously chip in the Chinese programmer isn't a
"decent device".

So seeing the 2 volt Vhi on just one pin made me look at the test
board to see what was holding it low. lol



Maybe the Chinese programmer uses an open-drain output with a pull-up
to Vref rather than powering an active driver with Vref? It would be
very strange for an active driver to limit its output to 2V with only
4.7K pulling down (426uA nominal).

I'm not sure what circuit you are imagining. What you call Vref is Vcc
from the unit under test, which is 3.3 volts in the case. Also, passive
pullup/down is very slow compared to the logic it is driving. That is a
great way to create noise in your circuit.

I can only assume there is something between the Vcc in and the driver,
perhaps a protection circuit. The 2 volts was measured with no load
other than the voltmeter.

--

Rick C

 

[GaborSzakacs]

rickman wrote:

On 11/29/2016 9:01 AM, GaborSzakacs wrote:
rickman wrote:
On 11/27/2016 1:57 PM, Les Cargill wrote:
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.



All F's indicate a level problem on the data line(s) to me. Check
termination and levels - or watch it with a very high Z scope if you
can get the triggering right.

The return data wasn't all 1s. It was all 1s other than a single bit
which was zero. All ones can have multiple problems. The output is
one. TCK not getting to the chip is another.

Funny thing... I did a Google search on 0xFFFFFFFE and found my own
reply to someone else having a similar problem. In the end he simply
had an unknown connection issue which cleared up while fiddling with
it all. Seems the 0xFFFFFFFE result is a common problem when the
cabling is not right. In this case it was the TDI signal.


Adding a scope Heisenbergs the circuit but that may offer inspiration
in solutions.

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.


Are these inherently 3 volt parts? If not, ithe corcuit is
overterminated.

Not sure what you intended to say here. But I forgot to mention that
another issue that confused the debug was a difference between the
Lattice programming adapter and the Chinese device I bought a while
back and has been working ok. Seems the Chinese programmer only pulls
the outputs to around 2 volts leaving no voltage margin in the worst
case. I only see this on one signal as the others are pulled high.
TCK is pulled low as recommended by some reference I encountered a
long time ago. This prevents the single rising edge that would be
detected on power up. A 4.7K resistor shouldn't be a problem for any
decent device, but obviously chip in the Chinese programmer isn't a
"decent device".

So seeing the 2 volt Vhi on just one pin made me look at the test
board to see what was holding it low. lol



Maybe the Chinese programmer uses an open-drain output with a pull-up
to Vref rather than powering an active driver with Vref? It would be
very strange for an active driver to limit its output to 2V with only
4.7K pulling down (426uA nominal).

I'm not sure what circuit you are imagining. What you call Vref is Vcc
from the unit under test, which is 3.3 volts in the case. Also, passive
pullup/down is very slow compared to the logic it is driving. That is a
great way to create noise in your circuit.

I can only assume there is something between the Vcc in and the driver,
perhaps a protection circuit. The 2 volts was measured with no load
other than the voltmeter.

I think you imagined it right. It wouldn't be a good way to drive TCK.
Another possibility is that they used an active drive dircuit at some
higher voltage (3.3V or more) and then connect via a simple FET-based
level shifter like the old QuickSwitch parts. Then the active drive
would only go up to the point where the FET starts to turn off because
its source gets within Vgth of Vref. You'd need a pullup to get the
signal beyond that point. Your weak pulldown would fight that pullup
and limit the high drive. In any case it seems an odd way to build
a programmer, given the easy availability of LVCMOS buffers that can
work at low voltage while taking up to 5V on their inputs.

--
Gabor

 

[rickman]

On 11/29/2016 2:06 PM, GaborSzakacs wrote:

rickman wrote:
On 11/29/2016 9:01 AM, GaborSzakacs wrote:
rickman wrote:
On 11/27/2016 1:57 PM, Les Cargill wrote:
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.



All F's indicate a level problem on the data line(s) to me. Check
termination and levels - or watch it with a very high Z scope if you
can get the triggering right.

The return data wasn't all 1s. It was all 1s other than a single bit
which was zero. All ones can have multiple problems. The output is
one. TCK not getting to the chip is another.

Funny thing... I did a Google search on 0xFFFFFFFE and found my own
reply to someone else having a similar problem. In the end he simply
had an unknown connection issue which cleared up while fiddling with
it all. Seems the 0xFFFFFFFE result is a common problem when the
cabling is not right. In this case it was the TDI signal.


Adding a scope Heisenbergs the circuit but that may offer inspiration
in solutions.

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.


Are these inherently 3 volt parts? If not, ithe corcuit is
overterminated.

Not sure what you intended to say here. But I forgot to mention that
another issue that confused the debug was a difference between the
Lattice programming adapter and the Chinese device I bought a while
back and has been working ok. Seems the Chinese programmer only pulls
the outputs to around 2 volts leaving no voltage margin in the worst
case. I only see this on one signal as the others are pulled high.
TCK is pulled low as recommended by some reference I encountered a
long time ago. This prevents the single rising edge that would be
detected on power up. A 4.7K resistor shouldn't be a problem for any
decent device, but obviously chip in the Chinese programmer isn't a
"decent device".

So seeing the 2 volt Vhi on just one pin made me look at the test
board to see what was holding it low. lol



Maybe the Chinese programmer uses an open-drain output with a pull-up
to Vref rather than powering an active driver with Vref? It would be
very strange for an active driver to limit its output to 2V with only
4.7K pulling down (426uA nominal).

I'm not sure what circuit you are imagining. What you call Vref is
Vcc from the unit under test, which is 3.3 volts in the case. Also,
passive pullup/down is very slow compared to the logic it is driving.
That is a great way to create noise in your circuit.

I can only assume there is something between the Vcc in and the
driver, perhaps a protection circuit. The 2 volts was measured with
no load other than the voltmeter.


I think you imagined it right. It wouldn't be a good way to drive TCK.
Another possibility is that they used an active drive dircuit at some
higher voltage (3.3V or more) and then connect via a simple FET-based
level shifter like the old QuickSwitch parts. Then the active drive
would only go up to the point where the FET starts to turn off because
its source gets within Vgth of Vref. You'd need a pullup to get the
signal beyond that point. Your weak pulldown would fight that pullup
and limit the high drive. In any case it seems an odd way to build
a programmer, given the easy availability of LVCMOS buffers that can
work at low voltage while taking up to 5V on their inputs.

Once we get this batch of boards out the door, I will get both
programmers back and do a teardown to see what they use. I thought the
Chinese programmer was a copy, but I've noticed it does not produce the
same signals on the JTAG interface when failing. I haven't tried to
compare the signals when it works ok.

--

Rick C