First FPGA PCB - JTAG Unable to Scan Device Chain

[TeddyPython]

Hi,

A little backstory first. I'm new to FPGAs, having started with a cyclone IV E dev board designed by WXEDA. I have since wanted to create my own PCB with the same Cyclone IV FPGA. To achieve this I drew inspiration from the WXEDA board to allow me to place the necessary connections and support components (oscillator, flash, etc), along with a lot of help from Altera design documentation.

In my design (first attached PDF) used the same EP4CE10E22C8N as in the WXEDA schematic (second attached PDF), despite the actual WXEDA PCB carrying a EP4CE6E22C8N - the connections as far as I can make out are identical.

I soldered everything in my PCB together, powered it on and heard a high pitched buzzing from the 5V regulator. After much troubleshooting, I couldn't figure why this was happening so I replace it with a direct 5V from my HP E3631A bench supply. Problem solved - no more buzzing. I measured the output of the 3 linear regs - all very close to their rated voltages (within 2 or 3 mv).

I next plugged in my USB Blaster to my jtag (con 11 on page 6). Booted up Quartus Prime with a simple toggle module and opened the programmer. It detected the USB Blaster fine, but it says that it is Unable to Scan Device Chain.

This is where I am currently stuck. I am 99% sure that all the pins are correctly soldered. I've inspected them visually and with a multimeter continuity check (when powered off). Everything checks out between my PCB, my schematic, the WXEDA schematic and the Altera device pinout. Nothing seems to be shorted.

I can only think that there is something I have missed in my design which is causing a problem. I have tried to keep the jtag lines as short as possible (less than 4cm from pad to pad). I can share my PCB layout too (or photos or waveforms from oscilloscope), if anyone feels it would be useful to see.

Is there something I have missed in the design or my process for connecting the device for programming? Any help would be really appreciated as I have been really excited to getting this project together, but I'm out of ideas.

[kizmit99]

I did something similar - started with the same board you did, then made my own (although I moved up to the Cyclone 10).  I also spent a lot of time with the Altera/Intel data sheets and I ended up doing some things slightly different than you have - I'll list them here, only to give you some things to take a look at - I'm not claiming my way is right only different from what you have:
* I believe MSEL1 should be tied to VCCA - which should be 2.5V after a ferrite bead.  I highly doubt this is a problem.
* I used a 1K pulldown resistor on JTAG pin 1 - you have 4.7K
* I used 10K pullups on JTAG pin 5 and 9, also on nStatus, nConfig and Conf_Done on the Cyclone - you have 4.7Ks
* You are pulling nStatus and nConfig to 2.5V -- I believe these should be pulled up to VCCIO1 (which on mine (and yours) is 3.3V)

Of the differences noted above, only the last *seems* like it would be a likely culprit...

BTW - I didn't take any particular care with the JTAG traces.  I treated them as some of the lowest priority when routing.  Haven't had any JTAG issues on two boards I've assembled...

Just another note though -- I have managed to toast a USB Blaster by not paying attention and plugging it into a hot board.  Perhaps your Blaster is broke?

Good luck finding the issue!

[TeddyPython]

Thanks for the quick reply kizmit99 - really appreciated. To address each point (as much as for my own reference later);

* I think my schematic isn't clear here - MSEL1 is tied to 2.5V on my design - though it is a bit messy, overlapping some GNDs.
* JTAG pin 1 is 4k7 on the WXEDA - but it might be something I look at swapping.
* These 10k are 4k7 on the WXEDA - I'll swap them over if I'm all out of ideas.
* The WXEDA show nStatus and nConfig going to 2.5V through a series R, whilst VCCIO1 is to 3.3V - However I agree that this is most likely to be a culprit - I will try with some jumper wires tomorrow.

Thanks for the clarification about JTAG, I wasn't too sure at all how important they were.

I admit I did have an "oh cr*p" moment with the USB blaster, but I've since tested it on the WXEDA board and it detects the Device Chain fine... So I think I escaped unscathed on that one.

Any other ideas from others?

[kizmit99]

I just thought of one more thing...
I have found that oscillators in 4 pin SMD packages can be very deceptively packaged - specifically, the notched pad is not necessarily pin 1, it can sometimes be pin 4 -- WTH?

There was a note in the data sheet for one I was using that specially warned to ignore the 'special' pad and instead look at the writing on the package lid, then locate pin 1 at lower left.  Note - there was no pin 1 marking on the top of the package (unless you consider all of the writing to be the pin 1 marking) - and sure enough the notched pad in the batch I got happened to be pin 4 not pin 1.  So, just something else to consider...

[TeddyPython]

Thanks kizmit, I double checked the osc and it's good - with a 48MHz output going to the fpga. I think this osc packages rank up there with smd LEDs for the most confusing/ambiguous/non-standard markings lol.

I think I have made step towards debugging this...

I measured the voltages on the WXEDA (which uses 4k7 for pullups everywhere) and it has VCCIOx = 3V3, whilst the three config pins are pulled up to 2V5 with a series 4k7 each. I then checked my own circuit... And measured the following voltages...



Clearly something is up with these pins. Each resistor has 2.51V on the power rail side, but these much lower voltages between resistor and pin. Below is a (large) photo I've taken of the device. I'm sure I've got the correct orientation of fpga (pin 1 marked with the smaller dimple annoyingly, I think). Please excuse the excess flux, I've been resoldering various bits and pieces... I think I will next try to reflow the FPGA pins, making 100% sure that they are all connected and not floating, though I'm not sure that will fix anything as I've already verified that all power pins are soldered and not shorted. :/ Anything other steps?

EDIT: I've resoldered the FPGA but still have the same voltages on those pins. I've checked again and these three are still not shorted to ground.

[TeddyPython]

Another question I have is would the choice of flash IC affect the visibility of the FPGA on the device chain? The original design called for a EPCS4SI8N flash, but as that is not available I thought a IS25LQ040B-JNLE would be sufficient. Could this be part of the problem?

kizmit99, do you remember what you used in your own design?

[kizmit99]

I used a MT25QL128ABA1EW7-0SIT (https://www.digikey.com/product-detail/en/micron-technology-inc/MT25QL128ABA1EW7-0SIT/557-1790-ND/6622726)  -- I do recall that "any old" flash wouldn't necessarily work and that I seemed to have to do a lot of digging to find a currently available flash chip that would work (without going to the Intel branded part, which I recall being quite expensive).

I wouldn't think that a bad flash chip would screw up the JTAG interface - The JTAG interface should work even if the flash is empty (presumably also if corrupted)...  This is just me thinking out loud though, no in depth experience with them...

You mentioned that your 5v regulator had some kind of issue on the first power up - I'm beginning to wonder if maybe something got through to the FPGA and burned it out?  Do you have parts to build up another board (or the ability to replace the FPGA on your current board)?

[kizmit99]

Take a look at the Cyclone IV Device Handbook, section 8-6.
I'm pretty sure that since you're seeing nStatus and Conf_Done being pulled low that the device is stuck in Power-On-Reset (POR) mode.

If VCCA or VCCINT are not reaching correct operating voltages the POR circuit will reset the device.  So verify that you are seeing a solid 2.5V on all VCCA pins and 1.2V on all VCCINT pins...  At least with package you're using that would be feasible (with a steady hand).

I would also suggest double checking all of your VCC and GND pin assignments, including the footprints on your layout, to verify you have accidentally left one of those pins (VCCA or VCCINT) floating...

The signal you're seeing on the nConfig pin is also disturbing - pulling that pin low will also force a device reset -- so that could also be a root cause of what you're seeing.  Not sure what to suggest on that one though, as the pullup should be enough to pull that pin high, but you're obviously seeing a very suspect voltage level on that pin...

If all of those check out, then I would have to assume that your device is toast.

Good Luck!

[TeddyPython]

Yeah, I have temporarily removed the flash just to ensure there is no problem there for the time being.

I have thought that maybe the 5V supply is has damaged the FPGA, but on the other hand, the 5V is not supplying the FPGA directly and the three linear regulators seem to be working in perfect order, even when the 5V issue was happening, the FPGA supplies were 'solid'.

Thanks for the link to section 8-6. I see your reasoning for connection to VCCIO. If I can find some 10k resistors I'll make a modification and see what happens.

As it turns out I also became aware of the POR limitation through "Con€guring Altera FPGAs" (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cfg/cfg_cf51001.pdf). Just a bit disturbed about the 1.2V state.... I thought that maybe the supplies weren't conforming to the max POR times, but if the Cyclone IV Device Datasheet (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-iv/cyiv-53001.pdf) page 1-5 is anything to go by then that time limit should be (lowest max) of 3ms. The following measurement shows all three FPGA supplies switch on in less than 2ms. So no issues there.



I'll try raising those pins to 3.3V and report back... I don't think I have anything to lose at this stage.

Cheers.

[kizmit99]

I think, unless you have MSEL pins configured in Fast-Startup mode (which it doesn't seem like you do), you have at least 50ms for the power supplies to stabilize - so you look like you're in good shape on that front...

I'm assuming that's the 5V supply which start rising first and then has that burst of noise?  Assuming it is, I wouldn't imagine that being a cause for weirdness either (just it getting a little bogged down as the other regulators start up).

Right now I'd assume whatever the issue is, it's probably related to that odd voltage on nConfig...

[TeddyPython]

It's fixed and working...

The fault is a little embarrassing, but I'll post anyway in case someone else comes across such strange behaviour. It turns out that at least one pin must have not been properly soldered - but only very just. In a fit of desperation I flooded the pins with solder and flux and it was detected. I guess when probing the pins I was pushing down on the unconnected one just enough to make contact - despite trying carefully not to do just that!

As a side note, I had no trouble with my Flash memory substitution. It turns out the IS25LQ040B is a suitable replacement for the EPCS4SI8N which is no longer available. The IS25LQ040B is also far cheaper than the official Intel replacement, the EPCQ4ASI8N at $0.39 and $6.30 respectively.

Thank you for your guidance kizmit99.

[kizmit99]

Awesome - glad you found the problem 
Too bad you couldn't figure out exactly what pin it was, but I wouldn't have resoldered and retested each pin individually either 

Very good find on that Flash part -- I can almost guarantee I'll be looking this thread up in the future when I run out of my current stash of the ones I used ($2.15 each).  hard to beat 39cents...

[asmi]

I guess when probing the pins I was pushing down on the unconnected one just enough to make contact - despite trying carefully not to do just that!

I had exact same problem with a resistor, which tombstoned just enough to not touch the pad, but whenever I touched resistor with the probe, it made contact with the pad.
Which is why now I always include looking from the side under microscope into my post-reflow inspection!

[TeddyPython]

Smart idea, asmi. It's coming up to Christmas, maybe I'll put one on my wishlist and hope I've been well behaved this year.  Any recommendations/things to avoid that come to mind?

[asmi]

Smart idea, asmi. It's coming up to Christmas, maybe I'll put one on my wishlist and hope I've been well behaved this year.  Any recommendations/things to avoid that come to mind?

I use this one, but depending on how tall you and your desk are, you might want to choose SE400. SE400 has a working distance (distance between objective and the board) of about 23 cm, my SE410 is about 15 cm. I bought the version with all four magnification options (5x/10x/15x/20x), but in reality I use only x10 (for placement and soldering) and x20 (for inspections, as well as for working with extra small parts like 0201 capacitors).

[colorado.rob]

Smart idea, asmi. It's coming up to Christmas, maybe I'll put one on my wishlist and hope I've been well behaved this year.  Any recommendations/things to avoid that come to mind?

I use this one, but depending on how tall you and your desk are, you might want to choose SE400. SE400 has a working distance (distance between objective and the board) of about 23 cm, my SE410 is about 15 cm. I bought the version with all four magnification options (5x/10x/15x/20x), but in reality I use only x10 (for placement and soldering) and x20 (for inspections, as well as for working with extra small parts like 0201 capacitors).

I second the recommendation for the SE400.  That's the scope I use for assembly and inspection.  I can work using that microscope for hours without any fatigue.  For inspection, I also frequently use a USB microscope, especially when I need high magnification..  This is the one I use: https://www.ebay.com/itm/190932077059

[asmi]

I second the recommendation for the SE400. 

I bought SE400 at first too, but once I received it I realized it was too tall for me with my desk setup, so I had to exchange it for SE410, which fit right in!

[FranckS]

Hey everyone. This is my very first post on this forum

Same problem as @TeddyPython :

This is my first PCB design with a fpga. I'm using a MAX10 10M08SAE144C8G.

Power seems to be fine. 3.3v on all power pins (3.294v to be precise). Measured raise time is 1.2 ms. So well within specs limits (3ms on early gen MAX10, 10ms on later gen).

nSTATUS and CONF_DONE are stuck at 50mV despite stiff 1k pullups. Only nCONFIG is high. So my guess is the fpga is stuck in POR mode.

Therefore the JTAG interface is not responding.

I've tried to resolder several times all pins, as suggested by @TeddyPython. I don't see any short (at least none on power pins obviously) or bad solder. Besides, all IO pins are supposed to be hi-z during powerup so no interaction with other components should be possible.

I've been stuck on this problem for days and don't know what's my next possible move. Any help would be very appreciated.

[FranckS]

Found the culprit. I thought I had verified every power pin, of course there was one near the crystal I (pin 23) that I missed. There is a missing via to power between the pin and the .1uf cap. in my pcb design at that place. Glad I can move on now.

Cheers,
Franck.