Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20878 Discussions

Cyclone 10 power-up latches up

PhilipJ451
Beginner
1,540 Views

Hi all,

we have a number of designs that use the Cyclone 10CL025YE144 device. They are programmed by a Host CPU using PS mode.

Occasionally we run up against a batch of devices that appear to get into some kind of "latch up" condition when powering up where pins all seem to be actively pulled low. I say this because one of the IO pins has an LED (cathode) connected to it and this LED lights up, this surprises me because I thought that all IO pins remain Hi-Z until the chip is programmed.

In addition the nSTATUS line remains low where it is said that it should go high after a high-low--high transition of the nCONFIG line.

I have read the available data and as far as I can see it says that the supply voltages (3V3, 2V5 and 1V2) can come up in any order just so long as tey are monotonic and have reasonable rise time (between 50uS and 50mS) which ours do...

 

Does anyone have any advice or experience of this condition ?

Suggestions will be gratfully received

PhilipJ

 

Labels (1)
0 Kudos
16 Replies
AqidAyman_Intel
Employee
1,497 Views

Hello,


Intel Cyclone 10 LP is a hot-socketing compliance device where the I/O pins remain tri-stated during power up. The device does not drive out before or during power up, therefore it should not affect other buses in operation.


More info in this documentation from the link below:

https://www.intel.com/content/www/us/en/docs/programmable/683777/current/i-o-pins-remain-tri-stated-during-power-up.html


0 Kudos
PhilipJ451
Beginner
1,490 Views

Hello,

thank you for your reply, I have read the document you point to and I agree, it says the Cyclone 10 "is immune from latch up during hot-socketing".

_BUT_

we are definitely seeing an issue with our products were about 1 in 10 units presents a condition after power-up but before any programming takes place, were an IO pin that is connected to an LED (LED anode is connected to VCCIO, 3.3V with current limiting resistor) causes the LED to illuminate. The data states that "The Intel® Cyclone® 10 LP device family does not drive out until the device is configured and working" so this LED illumination can only happen if the IO pin is sinking current to Ground.

We are checking our production quality but it would be a stretch to think that 1 in 10 boards could all have a similar manufacturing "short-circuit" that would cause an effect like this.

The chip is also giving a constant low level output on the nSTATUS pin. The datasheet for PS programming mode states that it should go high after we toggle the nCONFIG line low and then high again. The nSTATUS pin also has a 10k pull-up resistor so something is pulling this line low as well.

Combining these 2 symptoms, we have to suspect that it is something going wrong with the 10CL025YE144I7G device.

Is there anything that you or your colleagues can suggest that we check to try and determine what is going on with these chips?

Are there tests that can be performed with the Quartus software and a JTAG device connected to the chip, to examine internal status ?

 

Thank you for your time and attention

Kind regards

PhilipJ

 

 

 
0 Kudos
AqidAyman_Intel
Employee
1,429 Views

Hello PhilipJ,

You can refer to various debug tools that are within the Quartus software. One of it that I can suggest to you is Signal Tap Logic Analyzer as per link below. You can utilize it to examine the internal status of your FPGA design.

https://www.intel.com/content/www/us/en/docs/programmable/683552/18-1/the-logic-analyzer.html


Regards,

Aqid


0 Kudos
PhilipJ451
Beginner
1,422 Views

Hi Again,

thank you for the information.

I am familiar with Signal Tap, I use it quite often to examine what is going on in my logic design.

My problem is that the FPGA is not allowing me to program it and as Signal Tap is compiled into my design I cannot get Signal Tap into the chip in order to debug with it.

My question was, are there any "chip status" registers within the JTAG part of the chip that can be read via the USB-Blaster before the chip has been programmed to determine why the  nSTATUS line (and it would seem all the other IO pins) remain low and sink current when the data-sheet says they should all remain in Hi-Z state.

 

regards

PhilipJ

 

0 Kudos
AqidAyman_Intel
Employee
1,395 Views

As far from my concern, I am not aware of any registers within the JTAG part of the chip that can be read before the configuration happened.


How about the conf_done signal? Is it high or not after the nstatus remain low? Can you share the snapshot of the signals?


Regards,

Aqid


0 Kudos
PhilipJ451
Beginner
1,377 Views

Hi,

once again thank you for your time and interest in my problem.

The conf_done line also remains low. In fact I think all the pins of the chip (except for the power pins of course) appear to be low and sinking current which is why I thought it might be some kind of problem with the chip latching up during power-up.

I have added an image that shows the rise of the 3 power rails at power up:

Orange is 3V3

Blue is 2V5

Purple is 1V2

Do they look ok to you?

 

I think I read something about "if an IO pin has a high signal on it, before power is applied to the chip this may cause a latch-up". Do you know if this is correct?

Many of the IO pins of the FPGA are connected to other devices in the design and I have not checked all pins to ensure that the above does not happen. The 3 power lines for the FPGA are themselves derived from a 5V PSU and it is possible that other devices which power directly from this 5V (although with 3V3 IO) may "come up" faster than the FPGA's own power lines.

Should I be concerned for this?

 

Kind regards

PhilipJ

 

 

0 Kudos
GLees
New Contributor II
1,362 Views

I had a similar-sounding problem with the MAX10 which has a known bug; some outputs are driven during configuration.  The work-around was to check the box labelled "Enable real-time ISP to allow background programming when available" in the programming tool.  Maybe this will work for you.

0 Kudos
AqidAyman_Intel
Employee
1,308 Views

Hi PhilipJ,


Have you give a try on the workaround suggested by GLees?






0 Kudos
PhilipJ451
Beginner
1,296 Views

I haven't because I have been rather tied up with other projects.

Also the suggestion of "setting an option in the programming tool..." is confusing.

The programming tool is out Host CPU that programs the chip using the PS method.

However it has prompted me to think, "would these chips also fail to program if I were using a ByteBlaster?" which I will try as soon as I get a bit of time.

Thanks to all for the continuing interest in my problem

 

regards

PhilipJ

 

0 Kudos
AqidAyman_Intel
Employee
1,143 Views

Hi PhilipJ,


Do you have any updates that you would like to share with us?




0 Kudos
PhilipJ451
Beginner
1,132 Views

Sadly, nothing helpful.

I tried using the USB blaster but it just couldn't find the JTAG chain in the chip so no further progress.

regards

PhilipJ

 

0 Kudos
GLees
New Contributor II
1,120 Views

The fact that your Blaster can't identify the JTAG chain suggests there's a problem lurking somewhere that needs to be fixed.  Whether or not it's related to your "latch-up" problem remains to be seen.

 

I won't tell you how to do your job, but I will tell you what I would do in your situation.  I would first resolve the JTAG situation and see if it has any bearing on your problem.  If not, then at least you're in a position to try the USB Blaster and see if you learn anything.  Either it does or doesn't help, with or without the check-box, etc.  These kinds of problem often take a lot of banging around before they get resolved.  It's not a linear process.  I'll quote my favorite line from the movie "Twelve Monkeys"; 

 

"Science ain't an exact science".

0 Kudos
AqidAyman_Intel
Employee
1,085 Views

Hi PhilipJ,


No worries. You can always post a new thread in this community forum if you have any progress or when you identify the real issue behind this.


0 Kudos
PhilipJ451
Beginner
994 Views

Hi,

I'm back on this problem again. Based on a previous reply I thought that I would look into why the Blaster (programmer) couldn't identify the chip and I captured the JTAG waveforms but the TDO pin is just outputting a constant low.

I have checked all the chips power pins and they all have correct voltages on them.

I have checked the GND pins and again they all seem to be soldered ok.

The only thing I can't check is, it would seem from the PCB layout drawing that there is a "heat spreader plate" on the underside of the chip we are using (10CL025YE144C8G). Our PCB design appears to allow for this to be soldered to the GND plane.

What would happen if this was not soldered to GND ? We have had some cases in the past (other designs) where our manufacturing sub-contractor makes a mistake and this pad is not solder pasted.

Does any of the internal circuitry connect through this pad instead of the normal GND pins ?

thanks

PhilipJ

 

0 Kudos
GLees
New Contributor II
988 Views

I had a problem years ago with (as I recall) a Cyclone III part that wouldn't configure.  In that family at least the thermal pad on the FPGA HAD to be grounded.  After reworking the board to ground the pad, everything configured properly.  I would search through the "pin connection guideline" document for your part and see if the thermal pad must be grounded.

0 Kudos
PhilipJ451
Beginner
968 Views

Hi GLees,

thanks for your reply.

We have spoken with our sub-contractor and they have said we should send the batch of boards back to them and they will "re-flow" them.

I will let you know what happens after I get them back for re-testing.

PhilipJ

 

0 Kudos
Reply