Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorCyclone III stuck at POR?
Hi,
I have problems to get a custom board work, the FPGA seems to be stuck in POR. It's a PCIe card with a EP3C10F256C7N. I attached an excerpt of the schematic to this post. I have 10 prototype boards, they all show the same problem: nSTATUS is at LOW level and we can't test the boards with JTAG. It's our the second design with a Cyclone III, the first one worked well. I checked the power supplies, they are well inside the limits. VCCINT is 1.196V, VCCA is 2.497V and VCCIO is 3,282V. I tried to vary VCCA and VCCIO some 0.1V up and down, but without success. VCCIO is sourced directly from the 3.3V of PCIe connector, VCCINT and VCCA are made from this 3.3V with linear regulators. All VCCIO are tied together to the same 3.3V power supply. MSEL[2:0] is set to 010, that should be AS standard POR with 3.3V configuration voltage. I measured the config and JTAG pins: nCONFIG: 3.3V nSTATUS: 0V CONF_DONE: 0V nCEO: 0.2V (open?) DCLK: 3.3V nCE: 0.9V (?) nCSO: 3.3V ASDO: 3.3V DATA[0]: 3.3V TDO: 3.3V TDI: 3.3V TMS: 3.3V TCK: 0V Can nCE or any other config pin hold the device in POR? The design has migration parts (EP3C5, EP3C16 and EP3C25), therefore I have more VCC and GND pins than required for the EP3C10 connected to the device. I checked all dedicated pins (configuration and power) against a Quartus II 10.1 generated pin list. I compared it with our schematic and with the PCB artwork, but I can't find any mistake. I didn't check all of the I/O connected to the board, but all peripheral devices are powered from 3.3V, so I assume that they're within the I/O limits. Where is the mistake? What other reason can hold the device in POR? Regards, Jürgen35 Replies
Altera_ForumSorry, I have to ask. What is the JTAG tool you are talking about?
- Altera_Forum
That's good to know. I'll try those things.
Rick - Altera_Forum--- Quote Start --- No, I can't. If it is held in reset should I be able to access it via JTAG? (I don't know the answer to this and have been searching the handbook for the answer.) --- Quote End --- There isn't a JTAG reset pin, so you should always be able to access the JTAG chain. Can you try using the JTAG tool from Quartus and toggling TCK, TMS, and reading out the IDCODE. Probe the board with a scope and see if there is appropriate activity on the pins. For example, if your TDI output from the FPGA back to your USB-Blaster is broken, Quartus will not detect the device, but you should see the TCK/TMS/TDI and TDO pins on the FPGA toggle. If you cannot get any activity on the TDO pin, then check for shorts. If there isn't one, then that would confirm that the FPGA is not responding to JTAG either. Cheers, Dave
- Altera_Forum
No, I can't.
If it is held in reset should I be able to access it via JTAG? (I don't know the answer to this and have been searching the handbook for the answer.) - Altera_Forum--- Quote Start --- I'm dealing with the same issue. Cyclone III stuck in POR. All rails are present that should be present. Rail timing/sequencing is not an issue per the handbook. It just stays in Reset until all required rails are in the required ranges. My nSTATUS line is pulled up with a 10k to 3.3V, but the chip side of the resistor is measuring to be ground. I've looked over my design for two days since receiving my new boards. I've checked my pinout in the schematic, checked my pinout in the layout, checked for proper orientation of the chip, checked the part number of the installed chip, checked all voltage rails, etc. I can't wait to figure this one out. --- Quote End --- Are you able to access the device via the JTAG chain? Cheers, Dave
- Altera_Forum
I'm dealing with the same issue. Cyclone III stuck in POR.
All rails are present that should be present. Rail timing/sequencing is not an issue per the handbook. It just stays in Reset until all required rails are in the required ranges. My nSTATUS line is pulled up with a 10k to 3.3V, but the chip side of the resistor is measuring to be ground. I've looked over my design for two days since receiving my new boards. I've checked my pinout in the schematic, checked my pinout in the layout, checked for proper orientation of the chip, checked the part number of the installed chip, checked all voltage rails, etc. I can't wait to figure this one out. Rick - Altera_Forum
Hello FvM,
--- Quote Start --- Regarding unusual "special" configuration circuits, e.g. pulling nCONFIG high, as long as you do't know the exact internal circuit connected to the pins and their operation, I would avoid these. --- Quote End --- Yes, I think that's a good hint. I'll try to simplify the config circuit to be closer to the Altera recommended circuit. --- Quote Start --- I wonder, if the ferrite bead without decoupling capcitor may cause unwanted ripple or even overvoltages on the device side supply node. --- Quote End --- The ferrite's resistance is too low to cause such effects. But the ferrite isn't useless, it will kill most of the noise caused by the device. For the EPCS device it's not really needed, beacuse it's only operated during the startup phase and does not cause continous noise. But especially for oscillators the ferrite significant improves EMI compliance. The reason why the decoupling capacitor is placed before the ferrite is that if it's placed directly at the pin, the noise will flow through the capacitor to the ground plane and cause EMI. That's how they told me in the EMI seminar, anyway. Regards, Jürgen - Altera_Forum
I didn't observe similar problems with C III yet, except for a customer, who tried E144 package with floating exposed pad. Regarding unusual "special" configuration circuits, e.g. pulling nCONFIG high, as long as you do't know the exact internal circuit connected to the pins and their operation, I would avoid these. You can place a decoupling diode and revert to the Altera suggested circuit. But you are most likely right, that this isn't the cause of problems.
I wonder, if the ferrite bead without decoupling capcitor may cause unwanted ripple or even overvoltages on the device side supply node. - Altera_Forum
Hello FvM,
--- Quote Start --- You didn't explicitely tell, but I assume that the device also isn't recognized at the JTAG interface? --- Quote End --- Right, the device doesn't respond to JTAG commands. This and the LOW nSTATUS pin are the reasons why I assume that the device is stuck in POR. --- Quote Start --- I assume, that some optional resistors at the configuration interface aren't populated (e.g. nCONFIG pull-down), otherwise, the above reported measurements won't be plausible. --- Quote End --- The parts marked with "NB" are not populated to the board. But the nCONFIG pull-down is populated, the pin is driven HIGH from outside by a PCIe to local bus bridge. It will pull nCONFIG high as soon it has finished it's initializing sequence that is longer than the FPGA's POR. So, while the FPGA is in POR, nCONFIG will be LOW. Some 100ms later it will be pulled HIGH, and that should start configuration. I did this the same way with a previous design with a Cyclone I. Do you think this should work with the Cyclone II devide, too? --- Quote Start --- A small detail, that I don't undertand is L3 at the EPCS supply pins without any bypass capacitors. --- Quote End --- Yes, this is how it's designed. L3 is a small ferrite that should stop EMI. I know it's unusual without a decoupling resistor at the chip's pin, but it was a recommendation from a EMI siminar and it worked well in former designs. Regards, Jürgen - Altera_Forum
Hello Dave,
--- Quote Start --- Also probe your power supplies to make sure they power sequence within the recommended time. --- Quote End --- The 1.2V and 2.5V supplies are made from the 3.3V supply by linear regulators. In chapter 10 of the Cyclone III handbook I found this statement: --- Quote Start --- The Cyclone III device family supports any power-up or power down sequence (VCCIO, VCCINT) to simplify system level design. --- Quote End --- So, power sequencing isn't really a problem, right? Regards, Jürgen
