EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

Programming Problem

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - Programming Problem

Goto page 1, 2  Next

rickman
Guest

Thu Nov 24, 2016 1:51 am   



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


Guest

Thu Nov 24, 2016 1:51 am   



Den onsdag den 23. november 2016 kl. 19.51.31 UTC+1 skrev rickman:
Quote:
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
Guest

Thu Nov 24, 2016 1:51 am   



On Wednesday, November 23, 2016 at 1:51:31 PM UTC-5, rickman wrote:
Quote:
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.

Quote:
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


Guest

Thu Nov 24, 2016 1:51 am   



Den onsdag den 23. november 2016 kl. 20.56.00 UTC+1 skrev Tim Wescott:
Quote:
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


Guest

Thu Nov 24, 2016 1:51 am   



Quote:
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
Guest

Thu Nov 24, 2016 2:21 am   



On 11/23/2016 1:58 PM, lasselangwadtchristensen_at_gmail.com wrote:
Quote:
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
Guest

Thu Nov 24, 2016 2:55 am   



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

Quote:
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
Guest

Thu Nov 24, 2016 6:18 am   



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

Quote:
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
Guest

Thu Nov 24, 2016 8:30 am   



On 11/23/2016 6:18 PM, Tim Wescott wrote:
Quote:
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

rickman
Guest

Thu Nov 24, 2016 8:30 am   



On 11/23/2016 6:18 PM, Tim Wescott wrote:
Quote:
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
Guest

Thu Nov 24, 2016 8:30 am   



On 11/23/2016 2:55 PM, Tim Wescott wrote:
Quote:
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

Les Cargill
Guest

Mon Nov 28, 2016 1:57 am   



rickman wrote:
Quote:
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.

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

Quote:
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
Guest

Mon Nov 28, 2016 8:30 am   



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


Quote:
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
Guest

Tue Nov 29, 2016 7:32 am   



rickman wrote:
Quote:
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 .... :)

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

Quote:

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

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

Quote:
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
Guest

Tue Nov 29, 2016 9:01 pm   



rickman wrote:
Quote:
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

Goto page 1, 2  Next

elektroda.net NewsGroups Forum Index - FPGA - Programming Problem

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map