Problem with EPM1270T144I5N programming

[Altera_Forum]

I have a problem with EPM1270T144I5N programming. 

Nearly half of the same batch (45 pieces) of this device failed to complete ISP.  I'm a totally green thumb in this field and don't know how to analyze. So I come here to seek some expertise.  Should I doubt the manufacturing process, for example MSD, and try to dry these device to see if it works? Should I doubt the device itself, and try to measure the I-V specification of the pins, or just cut it off to check?  Anyway, there must be something I can do before changing the defect device idrectly, right?  Could anyone do me a favor?

[Altera_Forum]

Hi, 

 Could you give some more details? Are you able to program some of these devices and some are failing? Are the programmed device configured correctly and works as is expected? I just hope that there isn't any board or configuration pin wiring related issue.  BD

[Altera_Forum]

Yes we can program nearly 50% of these devices and others failed.  

And the programmed device configured correctly and works as expected.   Since we have manufactured several times before, none of them has similar problem, I don't think there’s any thing wrong with the board or configuration pin wiring related issue.  I doubt the point is this batch of EPM1270xxxx, but know nothing about how to prove it.

[Altera_Forum]

Hi, 

 Apparently both of the device lots that are failing are based on die revision G, which may be suffering from issue "Failed power-up into user mode for slow VCCINT rise times or VCCINT rise profiles with dips or noise near the power-on reset (POR) trip voltage." Please refer to http://www.altera.com/literature/ds/es_max_ii.pdf for more details.   You could give it a try with new chips containing die revision code I or later to make sure that this does not occur. I don't know whether it would be possible for you to experiment with this, but let me know if you do get a chance to experiment.  Hope this helps.  Cheers, BD

[Altera_Forum]

Your message is important for us, whether it has relationship with current problem or not. 

 I would turn to our contract provider for new chips containing die revision code I or later.  If they can offer some, we can experiment with it. And then I will feedback the result, as well as following devlopment of the issue.  Thanks a lot.

[Altera_Forum]

Hi, BD, 

 Thanks for your concern and support. Here's one more message from our programming process.  I'd like your analysis and suggestion to help me figure the issue.

[Altera_Forum]

Hi, 

 You can refer to http://www.altera.com/literature/hb/max2/max2_mii51013.pdf for ISP related issues and recommendations. This may help you isolate the problem.   Did you try Autodetect in JTAG mode of Quartus II programmer? Is it showing you correct device?

[Altera_Forum]

Also, the devices that are shown indicate a mix of leaded and lead-free parts. lead-free parts contain suffix "N" at the end of part number, e.g., EPM1270T144I5N as compared to EPM1270T144I5. Can you confirm that silicon IDs for leaded and lead-free parts are same (or different) for the same part-package (EPM1270T144)? Can you run the autodetect/program on a bunch of leaded and lead-free devices to verify this? 

 I'm not sure, but my guess is leaded parts may have silicon ID ALTERA04-0 and lead-free parts may have silicon ID ALTERA04-1. If that's the case, both should work. The problem may be related to power supply issue or improper start up.

[Altera_Forum]

Thanks you guys. 

 I'm now starting off a one-week business trip, and ask your understanding for my absence.  I'll carry out your suggestions and report the result at once I come back.

[Altera_Forum]

Hi, 

Found this on fpga-faq. Hope this helps http://www.fpga-faq.com/archives/89125.html ------ Article: 89141 Subject: Re: Reprogramming one MAXII EPM1270 vs security bit set From: "Luis Cupido" <cupidoREMOVE@REMOVEua.pt> Date: Tue, 6 Sep 2005 17:26:25 +0100 Links: << >> << T >> << A >>   Hi,  Similar situation happened to a friend of mine. He found out that while inspecting signals with the scope or placing the finger over the Jtag lines the MAXII loaded fine.  Altera did release a note about how sensitive some MAX II devices were regarding the electrical behavior of the JTAG signals... can't remember where it is but you will find it for sure at the altera site.  Over here all worked fine, but I do have a very long JTAG cable (2m) with the original byteblasterMV it sometimes fail :(  Looks like silicon versions respond differently... the ES (engineering  samples) devices were more picky than the regular ones ! but that is not scientific knowledge, just my impression.  Since on the long cable (that is more convenient here) it works always I just forgot about this issue and keep on developing the VHDL :)  Luis C.   <abeaujean@gillam-fei.be> wrote in message  news:1125911324.912543.131210@o13g2000cwo.googlegroups.com... > Hi group, > > I would like to share an impression I have. > > Trying to erase and/or reprogram one Altera MAXII EPM1270 device using > the Quartus 5.0 Sp1 Web free edition software and the ByteBlasterII > programming adapter kept on failing (same thing with ByteBlasterMV and > previous revision of the soft). > > After considering lots of possibilities (missing pullups, pulldowns, > JTAG clock with glitches, although none observed), I finally decided to > have the component de-soldered and a new one resoldered. > > IT NOW WORKS. > > Re-thinking the whole thing from the start, I now wonder if this > behaviour is not due to the previous use of the security bit. I > remember I set the security bit once on that device (on two different > prototypes, both of which were exhibiting the same problem). > > The security bit, once set, should I believe not prevent the component > from being erased and re-programmed (am I right or wrong ?). If you > read the MAXII specification, it seems so. > > The symptoms were : > > Error: Can't recognize silicon ID for device 1 > Error: Operation failed > > on both prototypes. > > Both prototypes are now working with the new soldered components. > > Has anyone experienced such a behaviour before ? > > So, I do believe that the problem could be once the security bit is > set. > > It could also be due to an incorrect definition of the length of two > non Altera devices part of this JTAG chain (4 instead of 16), but > anyway it is so strange that one could set a condition in the component > that prevents it from being re-programmed. > > Software bug ? > > Any idea ? >  -------

[Altera_Forum]

Actually the security bit will not cause the problem if you want to erase the device and reprogram it. The security bit is only used to prevent user from reading back (examine) the data of the programmed device.  

 If all the VCCINT & VCCIO pins are powered up and programming still has problem, I would suspect that the JTAG signal's integrity might be causing the problem. You might want to probe the signals, and also make sure that the VIH & VIL spec is not violated.