Recompile of design in Q11.0sp1 results in .SOF that will not load JTAG-ID mismatch

The expected JTAG ID is based on the device. Each device/package has a unique identifier, and is not under the user's control.

It looks like it initially finds the expected ID, but later finds 0xffffffff.

How do you recover from this? By cycling power? When you attempt to configure the device does the progress bar make a little or a lot of progress before the failure?

Do you have any backups that you can recover an old .sof file and load it using the newer programmer to confirm your hardware is working?

Try using the JTAG Chain Debugger (under Quartus' Tools menu) to test the JTAG chain, and/or the command line jtagconfig utility to read the ID(s) of connected devices.

I have cycled power. And yes, I have other .SOF files generated from previous builds. And they load just fine, every time. And yes, the JTAG debugger says the part is present.

That is what is so infuriating and perplexing. Everyting seems to check out. Except that it does not work.

bash-3.1$ jtagconfig

1) USB-Blaster [USB-0]

020F20DD EP3C16/EP4CE15

bash-3.1$

Looks good to jtagconfig.

bash-3.1$ nios2-configure-sof ../../../xxxxxx.sof

Info: *******************************************************************

Info: Running Quartus II Programmer

Info: Command: quartus_pgm --no_banner --mode=jtag -o p;c:/src/xxxxx/xxxxxxx.sof

Info: Using programming cable "USB-Blaster [USB-0]"

Info: Using programming file c:/src/xxxxx/xxxxxxx.sof with checksum 0x0036C311 for device EP3C16F256@1

Info: Started Programmer operation at Sun Dec 18 19:56:19 2011

Info: Configuring device index 1

Info: Device 1 contains JTAG ID code 0x020F20DD

Error: Can't configure device. Expected JTAG ID code 0x020F20DD for device 1, bu

t found JTAG ID code 0xFFFFFFFF.

Error: Operation failed

Info: Ended Programmer operation at Sun Dec 18 19:56:20 2011

Error: Quartus II Programmer was unsuccessful. 2 errors, 0 warnings

Error: Peak virtual memory: 141 megabytes

Error: Processing ended: Sun Dec 18 19:56:20 2011

Error: Elapsed time: 00:00:01

Error: Total CPU time (on all processors): 00:00:00

bash-3.1$

Diff your .qsf files between the 9.1sp1 version and 11.0sp1 one to see if anything looks suspicious.

On the off chance that there is a quirky bug in that release, maybe you can upgrade to the latest version (11.1SP1)

Thanks. I did that. And I even went back and created (from scratch) a 9.1sp2 project with a smiple SOPC and just tried to build and download it.

It behaves the same.

I *want* to believe my JTAG USB-Blaster has gone flaky or that my board is flaky.

But I keep coming back to an .SOF that I compiled (with 11.0sp1) that loads reliably each time. And so I am having trouble believing my Blaster or board is at fault (yet).

And if I go and create a .jic file (I am using EPCS16 to configure) and use the Quartus programmer to progam the EPCS flash using the 'factory' .SOF, that seems to load as well and the flash operation succeeds. But after a power cycle the FPGA does not seem to configure.

So maybe I have something that got disturbed in how the .SOF is being generated. But even that seems unlikely. And if I repeatedly try to program the .SOF, perhaps once every 10 or 12 times in a row, the programmer will actually complete reporting success. But still, the FPGA does seem to be configured properly.

Power cycles, unplug/plug of USB Blaster, recompiles, everything I can think of (including the painstaking diff of the the various .qsf files) and I have nothing to go on.

I do note that jtagconfig (or jtag debugger) will seem to report the device present then not report it then report it, and then not again, as if something is making the JTAG connection intermitent.

yet that old .SOF loads every time and seems to still work.

no clue.

Good idea. And the results are baffling to me.

If I load my known good .SOF (which loads each time without issue) and run the "loop until stopped" it runs, well, until I stop it (for a long time let's say).

If start my device from a power-up it runs for between none and perhaps at most a handful of iterations before bailing out with an error.

If start my device from a power-up, auto-detect it in the programmer, add the EPCS16 device, and run 'erase' it completes. If I run a 'blank check' after that, it completes. If I then run the JTAG IDCODE iteration test it runs continuously.

So that really tells me that the FPGA and JTAG are working and that it is something else. I just don't know what.

I am not sure what the device does when it is loaded with a 'bad' .SOF (nor how that would be possible). Could doing so cause the JTAG to blink out?