Cyclone 10 power-up latches up

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

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

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

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

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

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