Cyclone IV E JTAG issues - VCCA voltage level

Yeah, thanks, the thing is, the TDO signal is JUST A TRACK to the header, no pullup, pull downs, nothing. So my suspicion is that possible the pin driver got damaged by the USB blaster. It could be that the USB blaster is damaged, putting to high a load on the TDO pin, thus damaging it.

BUT, whilst I can program, I will try to sort out the configuration from the EPCS through the TXB0304. I can tell you I did not spend a lot of time on selecting this device and will probably pay the price now. The datasheet shows it can handle 150Mbs, so I figured it would be ok for the config data.

Well,

that sounds very strange.. if there is nothing on the "Output side" of the tiny logic that has a low impedance (or is a high capacitive load) that kills the TDO Output when driven by the cyclone, I'd assume there is still something strange on your board... Nevermind the Input of the tiny logic is a very high impedance thus I'd still assume either the supply of the TDO "bank" is not as stable as it should be or the board has some bug on the TDO line.

Have you checked the TDO Signal on the tiny logic Input to be a valid Signal? Otherwise - I'm afraid - this fix might not last very Long...

But that should not minimize my lob for your work on the Problem :-D

Well, some success at last.

I cut the TDO track and inserted a tiniLogic buffer i there to lift the level of TDO to 2V5.

Now the JTAG works, the device configured and enters user mode normally.

I have a single LED active!

NEXT STEP:

get the EPCS16 programmed and booted from.

--- Quote Start ---

Hi there,

I assume U23 is some level shifter - I'm not quite sure if this may not cause timing issues when configuration is to be loaded from the EPCS4 as this defintely adds twice to the timing on DCLK and Data..

Some things to mention:

The configuration scheme (0010) is for active serial, 3.3V(!). As you wrote 1.8 => 2.5V, the EPCS is powered by 2.5V, this requires MSEL configuration as (0011)...

The DCLK being some quite strange signal (more a sawtooth rather an rectangular signal) - is this due to the scope's limitation (bandwidth)?

I have to check the rise time on my board for nStatus, but even this signal seems for me to be not really "quick" enough at High level..

Nevermind - if the DCLK is operated by the Cyclone, this indicates the FPGA is out of internal reset and as there are just two "blocks" I would assume there must be some problem with the configuration data (is there any pof stored in the EPCS). Seems like the configuration cycle ends as the internal configuration controller does either not receive any data (put the scope on Data0) or the received data indicate not being for this EP4CE115...

I'll try to record these signals on my board meanwhile...

--- Quote End ---

Yes, it is a level converter. The one side connects to FPGA @ 2V5 and the other to EPCS @ 3V3, so it should be ok. BUT, I am not there yet. The EPCS is still blank and I have disabled the level converter. I have found out that the status line is going high and at about 1V2 the device is officially out of reset. Thus DCLK start to see if it can configure, but since EPCS is blank, it fails and then later tries again.

This is all good news since it means the device is happy with the power rails.

So now I am back to the JTAG port.

1. Power is ok and POR can complete

2. TCK to device is looking good at 2V5 (very little overshoot)

3. TMS to device is looking good at 2V5

4. TDI to device is also looking good

5. tdo responds to all of this but the level is sub 1v

Added a pullup to the TDO, still same voltage

Disconnected pull up and wire from Blaster, voltage out of TDO still just 1V.

Quartus jtag debugger says the TDO is stuck to ground, which makes sense since the 1V signal is looking like a low to the blaster.

Hi there,

I assume U23 is some level shifter - I'm not quite sure if this may not cause timing issues when configuration is to be loaded from the EPCS4 as this defintely adds twice to the timing on DCLK and Data..

Some things to mention:

The configuration scheme (0010) is for active serial, 3.3V(!). As you wrote 1.8 => 2.5V, the EPCS is powered by 2.5V, this requires MSEL configuration as (0011)...

The DCLK being some quite strange signal (more a sawtooth rather an rectangular signal) - is this due to the scope's limitation (bandwidth)?

I have to check the rise time on my board for nStatus, but even this signal seems for me to be not really "quick" enough at High level..

Nevermind - if the DCLK is operated by the Cyclone, this indicates the FPGA is out of internal reset and as there are just two "blocks" I would assume there must be some problem with the configuration data (is there any pof stored in the EPCS). Seems like the configuration cycle ends as the internal configuration controller does either not receive any data (put the scope on Data0) or the received data indicate not being for this EP4CE115...

I'll try to record these signals on my board meanwhile...

I wish there was a document showing the startup state machine of the FPGA, i.e. how the resets are done and at what voltage level a rail is considered good.

Then showing the states as the device tries to get config data after reading msel etc.

Then at least one can follow some process of debugging the problem.

Bummer, I must have made a mistake last night. All the rails are indeed correct. Which is good since I then did not miss a DRC error.

I measured each power pin on its via while triggering the scope on the nStatus pulse so make sure the rail is ok and that there is no voltage dip when the device tries to come out of reset. All pins are ok.

I attached 2 scope shots, one showing the recurring nStatus pulse and the second same pulse, but zoomed in a bit more.

I also attach the sch for the power and config page. (the pullups for the TDI and TMS and pulldown of TCK is on the top level at the connector). On the FPGA connection, where you see 1V2,# define to 1V and 1V8 is# define 2V5 after the rail adjustments I made. I am not planning on using any plls, this i did not bother with separating the pll rails from the int rails.

Let me know if you see something weird.

EDIT: If I pull nConfig low, the pulse on nStatus obviously goes away (device being in reset) and then reappears when nConfig released.

EDIT: did some more measurements and photo3 shows the nStatus pulse together with the DCLK signal.

Again, I appreciate the help.

Ivor

CarlHermann, 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.

hi,

"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?"

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...

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 Start ---

Hi,

in case you are about to remove the BGA, I would suggest to use this replacement as an option to check the correct voltages at the power pins, configuration pins ans the interconnection between these pins and the pulls... Just to ensure that everything is ok with the PCB itself...

It's difficult to measure at the pins with BGAs... :-)

--- Quote End ---

Got the second board of the two that were built the same time.

Before applying ANY power, I adjusted all the voltage rail to be as follows:

Vccint = 1.015V

Vcca = 2.423

Vccio = 3.273

The JTAG pins bank has VCIO of 2.423 volt.

All pull ups are checked.

nConfig goes high, nStatus seems to try to go high, but then is pulled low again, this happens every 65us.

Look very much like a POR event, but the voltages looks in range. Also checked the voltages on the scope and they are not drooping.

Any idea why the device would keep resetting. and why every 65us?