Cannot detect MAX V cpld and Cyclonne 5GX in the same jtag chain

[FFULC]

Hi

I have a new circuit card design with a Byte Blaster 10 pin header connected via jtag to a MAX 5M40ZE64 and then a Cyclone 5CGXFC5C6. The Quartus programmer cannot detect the chain.

When I run jtag diagnotics it detects the Cyclone (2nd device) but says the TMS or TCK are grounded at the first part (unidentified). When I put the scope prob on the TMS and TCK CPLD pins I see activity. If I bypass the MAXV (by shorting TDI to TDO pins at the MAXV) I can program the Cyclone.

Is there something in my setup that is wrong and causing the CPLD to remain undetected ?

Another thing worth pointing out is that the schematic is drawn for a 5M80ZE64I5N but the part fitted on the cards is a 5M40ZE64A5N. Is there any differences in pin out?

Thanks

Frank

[FFULC]

@JohnT_Intel can you help ?

[ak6dn]

You don't supply your schematic, but I wonder on how you set the VCC levels for the JTAG blocks on each part.

Are you setting them to be compatible levels (ie, all 3.3V I/O) between the two devices and your JTAG programmer?

[FFULC]

Hi @ak6dn both jtag blocks in the cpld(U6) and fpga(U1) are running at 3.3V

[ak6dn]

Well, don't see anything obviously wrong with your schematic.

You have the option to bypass the MAXV device, but not the FPGA device.

Is there a way you can check the JTAG response with just the MAXV device on the JTAG chain?

[FFULC]

Hi @ak6dn  

Yes if I bypass the MAXV I can successfully program the FPGA, I'll need to modify the board to isolate the MAXV. I'll look at that next.

One thing to mention is that I am using MAXV40ZE64 on the MAXV80ZE64 footprint, I presume there are no pin differences ?

Also I have DEV_CLRn and DEV_OEn floating is this an issue? Also all unused IO are floating

[FFULC]

Hi @ak6dn I have just put a scope probe on the jtag pins of the MAXV, see attached. The first two pictures attached show the TCK (ch1) and TMS (ch2) during testing the jtag chain. The clock looks pretty good, this was a concern. Third picture shows TCK and TDI - does the device latch data on the rising edge of TCK ? Fourth picture shows TCK and TDO 

So I never see any activity on the TDO output pin from the MAXV but when I test the JTAG chain in the Quartus Chain Debugger it still manages to detect the downstream 5CGX. How does it do this when the TDO line that feeds in to the TDI pin of the Cyclone has no activity on it ?

I have also checked all the VCC pins and all look good.

[ak6dn]

Re: JTAG, yes the TMS and TDI lines are sampled on the rising edge of TCK. TDO will change on the falling edge of TCK.

This is what the JTAG standard calls for so different devices can interoperate in the serial daisy chain.

Your scope shots all look good, I see no obvious waveform issues.

AFAIK DEV_CLRn and DEV_OEn should not affect the JTAG interface.

As to the JTAG test, it may just be using TMS to broadcast to all devices and not care about TDI going into any device. Just guessing.

On boards I design, I always provide resistor stuffing options to bypass around every JTAG device in the chain as a build option.

So we can easily build depopulated boards with missing JTAG devices, or to shorten the JTAG chain to specific devices only. My 2c.

I think at this point you need to isolate to just the MAXV device to get it up on JTAG. It could be a one off bad device or board issue too.

[FFULC]

Hi @ak6dn I have isolated the MAXV in the chain and still no luck I would like to send the cards back to the board assembler and get the part changed but they have no stock - long lead time issues everywhere ! Perhaps I'll send it back anyway and get them to remove, recheck the central gnd pad connection and then reflow the same device. But is there anything else that I can try first ? I have read that 2nd hand parts already programmed may have the jtag interface disabled but the supplier is adamant that the parts are brand new. Is there anything else that causes an inactive TDO ? Thanks

[ak6dn]

Unfortunate. Not a lot of other options.

In the past with issues like this I would send the board out for an XRAY to see if there were any obvious physical anomalies in the chip to board connection.

That can provide useful information, but it is informative only.

At this point I think your fix is to have the part removed, reballed, and reinstalled.

Depending upon the nature of the problem it may or may not fix it.

If the actual PCB fab is bad, or the chip is defective, it still won't work.

But if it was an assembly error it could correct it.