Honored Contributor
Honored ContributorCarlHermann, First I want to thank you for supporting me during this problem. It helps an incredible amount to have someone to bounce ideas off, and to generate new paths of investigation. I really do appreciate your help.
--- Quote Start --- "trying to go high" sounds not like there is a stable (even perhaps short) pulse but some rise in voltage which does not really reach anything near to a high level... This definitely - as there is nothing than the Pullup and the Pin being connected to the line - indicates the Cyclone not finishing POR. The question is "why?" --- Quote End --- I agree with this. --- Quote Start --- Can you be 100% sure, that there is no mistake in layout or manufacturing that disconnects either on of the power or gnd pins (thus triggering the Built-In Brown-Out / Power fail detection reset) and that the pull-Up is wired to the Cyclone / the 2.5V? nStatus is bidirectional, thus if e.g. the Pull-Up is broken, not soldered correctly or not connected to VCCIO the missing "High" is detected and restarts configuration... Maybe worth checking... --- Quote End --- You hit the nail on the head. Last night while staring at the pulses on nStats, I measured each of the voltage rails. Later I realised that I never actually measured the voltages on ALL the fpga power vias. So I did that last night (about midnight) and low and behold, the VCCINT has some disconnected pins. I have a regulator at the point of load feeding into the via grid under the FPGA, but for some reason ( I suspect incorrect copper pour sequence) the VCCINT section got split in two by a ground section. This should have been pick up by the DRC as an unconnected route. I will check later as to why I missed the DRC error. I decided last night it would be better to remeasure all the pins again and then do the mode while I am fresh. I will report back with the results. --- Quote Start --- Is there anything connected to nConfig that externally resets the Cyclone (nStatus goes low with nConfig being driven low) or is nConfig initially going high and remains a stable High? Besides what's written in the handbook... I may have to recheck this, but iirc * nconfig goes high => reset condition removed * nStatus goes high => internal device reset "do this an that" completed, device can accept configuration data * Conf_Done goes high with device configured Even with no data (e.g. blank Config device or nothing by JTAG) the nStatus should stay high as long as there is no interrupt on the power lines... (having read through the configuration section I did not really found the magic 65µs...) --- Quote End --- I have read the handbooks like crazy but also did not find anything about the 65us. As far as nConfig goes, I did have an EPCS16 on board, but I disabled it for the JTAG testing, so the nConfig goes high(according to scope) and never triggers low again.
