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
Reply to
rickman
Loading thread data ...
Den onsdag den 23. november 2016 kl. 19.51.31 UTC+1 skrev rickman:
pull-down or series resistors of the wrong value?
Reply to
lasselangwadtchristensen
The value 0xfffffffe is -2 in two's complement. It might be indicating an error code you can look up.
Best regards, Rick C. Hodgin
Reply to
Rick C. Hodgin
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
Reply to
rickman
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 
 Click to see the full signature
Reply to
Tim Wescott
or rising voltage if the data is sent LSB first
Reply to
lasselangwadtchristensen
Have you got the parts from a reliable source? I had a similar issue ("chec ked everything we can think of", failure rate about 20%) once. After weeks of searching in turned out that we have bought counterfeit parts... (It wer en't FPGAs, however, but application processors...)
Thomas
formatting link
- Home of EEBlaster and JPEG-Codec
Reply to
thomas.entner99
Then it would be much easier to believe a reliable 0 LSB with all ones following.
--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott
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
Reply to
rickman
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
Reply to
rickman
BTW, thanks to everyone for the suggestions. :)
--

Rick C
Reply to
rickman
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.
Are these inherently 3 volt parts? If not, ithe corcuit is overterminated.
--
Les Cargill
Reply to
Les Cargill
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.
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
Reply to
rickman
Sorry; my visual cortex returned all 1s for the 0xFFFFFFFE .... :)
That's a scream.
Woohoo! Fixed.
R(termination) too low. Not enough current, IOW...
Yuck.
:)
--
Les Cargill
Reply to
Les Cargill
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
Reply to
GaborSzakacs
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
Reply to
rickman
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
Reply to
GaborSzakacs
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
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.