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

[Altera_Forum]

I am at a loss to understand why Q11.0sp1 is generating an .SOF which fails to load on a CycloneIII 3C16. 

 The error I keep getting is:   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, but found JTAG ID code 0xFFFFFFFF. Error: Operation failed   All I did was change some top level logic and recompile. I did nothing to modify settings. The previous design was created with 9.1sp2 and I imported it into 11.0sp1. It had been compiling fine. And now, not.   I have re-checked the devices settings. I cannot find where Q11 gets this value 0x020F20DD from or why now it is failing.   Any help would be much appreciated.   Dave

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

bash-3.1$ jtagconfig 

1) USB-Blaster [USB-0]  020F20DD EP3C16/EP4CE15 bash-3.1$   Looks good to jtagconfig.

[Altera_Forum]

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$

[Altera_Forum]

Programmer first says it has the correct device then says it does not.

[Altera_Forum]

And thanks for he response. In answer to your question about the progress bar, when I use the GUI, it does not show any progress but fails immediately.

[Altera_Forum]

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)

[Altera_Forum]

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.

[Altera_Forum]

Using the GUI JTAG Chain Debugger's IDCODE iteration test in a looping mode (run until stopped or run N iterations) might help to see if your chain is indeed intermittent.

[Altera_Forum]

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?

[Altera_Forum]

--- Quote Start ---  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?  --- Quote End ---    I can see problems if a 'bad' .sof is loaded that has a lot of mis-configured pins that cause I/O conflicts & subsequent power rail or noise issues.  edit: you might also compare the .pin files from older and newer versions

[Altera_Forum]

I agree and I appreciate you raising that point. I did verify that the pin assignments (appear to be) identical. Moreover, I did not change them through this process. I made logic changes and recompiled and along that path (and irrevertably) the the design stopped being able to get loaded. 

 I admit it is most likely somehing I did. And I will go back to the pins and assignments again to be triple sure.   Thanks for you suggestions.