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 Previous  1, 2

rickman
Guest

Wed Nov 30, 2016 12:55 am   



On 11/29/2016 9:01 AM, GaborSzakacs wrote:
Quote:
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
Guest

Wed Nov 30, 2016 2:06 am   



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

Wed Nov 30, 2016 2:58 am   



On 11/29/2016 2:06 PM, GaborSzakacs wrote:
Quote:
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

Goto page Previous  1, 2

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