Stratix V full reconfiguration only works conditionally

[Altera_Forum]

On my Stratix V board, the ability to do a full reconfiguration of the device by asserting !nCONFIG is dependent on the state of the device. 

I have never seen this before, nor seen it documented.  The 5SGSMD3E2H29C3 is connected to an EPCQ256 in a x4 configuration. Powerup configuration works in all circumstances. My design also implements a avalon serial flash controller to boot the Nios from EPCQ. The Nios boot from EPCQ also always works on powerup.   The following seem to prevent reconfig from properly executing:  1) Configuring the device in x4 mode. When this is done, only powerup config works. x1 configuration must be used for reconfiguration to reload from EPCQ  2) If the Nios is allowed to boot from flash, reconfig won't work. If boot is inhibited by asserting reset while powering up, reconfig will work, repeatedly. Once reset is released and the Nios boots, reconfig stops working.  It appears that it is maybe the boot copier that is the problem in situation 2. With only the FPGA image (sof) programmed in flash, I can load my .elf with the debugger and run it, and reconfig still works.   Quartus II 13.0 with SP 0.23 and 0.24  Edit: Once the device is in the 'bad' state, reloading the .sof via JTAG while holding reset DOES NOT re-enable reconfiguration. So there is some state in the device that is not affected by an sof load.

[Altera_Forum]

another test sequence and results: 

 erase flash convert A.sof to A.flash load A.sof via JTAG program A.flash into EPCQ with nios2-flash-programmer reconfig - fail powerup - success reconfig - success reconfig - success verify A.flash with nios2-flash-programmer reconfig - fail load A.sof via JTAG reconfig - fail powerup - success verify A.flash with nios2-flash-programmer do NOT attempt reconfig load A.sof via JTAG reconfig - success  :confused:

[Altera_Forum]

Do you have an Altera Stratix V development kit that you can reproduce this test on? (I don't have one, so cannot do it for you, sorry) 

 If you reproduce the issue on an Altera kit, then you can file a service request along with the procedure required to regenerate the issue. I've found the support pretty good if I ask the questions with enough detail.  Cheers, Dave

[Altera_Forum]

I don't have a dev kit available. I was hoping someone here that has a devkit or their own design could confirm or deny the existence of the issue, and if it does exist point to a user error causing it. 

I think in the case of the kit boards that have both serial and parallel flash config options most times it will the the parallel that is getting the workout. I've filed an SR. Thanks.

[Altera_Forum]

--- Quote Start ---  I don't have a dev kit available. I was hoping someone here that has a devkit or their own design could confirm or deny the existence of the issue, and if it does exist point to a user error causing it. I think in the case of the kit boards that have both serial and parallel flash config options most times it will the the parallel that is getting the workout. I've filed an SR.   --- Quote End ---   How about this;  1. Create a minimum design which only uses say an LED   Create a Tcl script to synthesize that design, including creating the pin assignments, and tri-stating unused inputs.  2. Synthesize it for your board  3. Document the procedure to reproduce the failure (as above but with more detail)  4. Synthesize it for the Stratix V development kit  5. Ask the engineer that responds to your SR to perform the same sequence on the kit  The engineers at Altera have access to the kits. They sometimes have to wait while they borrow one "from the factory".  If you make the SR engineer job simple, then they have a harder time ignoring you :)  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  On my Stratix V board, the ability to do a full reconfiguration of the device by asserting !nCONFIG is dependent on the state of the device.   --- Quote End ---   You can also issue a reconfiguration request via JTAG, have you tried that?  I recall writing some Tcl to do this that works with quartus_stp. I can dig it up if you want to try it.  Cheers, Dave

[Altera_Forum]

The design in question is very basic but does have a flash interface, which seems to be part of the reconfig problem. I've offered to port my design if they have a devkit available. 

The simple design I used is actually based on a sample design they sent me to debug a possibly related issue (http://www.alteraforum.com/forum/showthread.php?t=41392).

[Altera_Forum]

Yeah I'd like to give a JTAG initiated reconfig a try. Does it use PULSE_NCONFIG?

[Altera_Forum]

--- Quote Start ---  Yeah I'd like to give a JTAG initiated reconfig a try. Does it use PULSE_NCONFIG?  --- Quote End ---    Yep.  Rename the attachment _tcl.txt -> .tcl and source it from quartus_stp and you can play with the routines in it.  Cheers, Dave

[Altera_Forum]

Thanks Dave. Very nice. I'm not worthy ;-) 

 Got the same results as my (debounced and pulse extended) nCONFIG switch, but it's nice to have more in my toolkit.

[Altera_Forum]

--- Quote Start ---   Got the same results as my (debounced and pulse extended) nCONFIG switch, but it's nice to have more in my toolkit.  --- Quote End ---    Excellent.   Now if only a kind soul had a Stratix V kit that they could test ...  Cheers, Dave

[Altera_Forum]

The symptoms of the failed reconfig are very similar to the first one listed in the S5 errata sheet 

false configuration failure in active serial multi-device configuration x1 mode "The failure is indicated by CONF_DONE going high followed by nSTATUS going low and reconfiguration is initiated repeatedly" except I'm not using a multi-device configuration, and I'm also seeing INIT_DONE go high for about 925uS before each re-initiation  A couple of other observations from today's testing:  I installed SP1 for QII 13.0 Without the additional patch (.23), no reconfiguration worked at all, even when only the sof was flashed. As usual, powerup configuration worked. I eventually installed patch .24 as well. With SP1.23 and (1.23 1.24) the reconfig behavior is the same as before.  Something else is unusual: nios2-flash-programmer always erases all affected sectors prior to programming, even if they were previously erased (with --erase-all) or if the data to be programmed should be identical to the flash contents. A --verify option is successful, so the flash can be read and is confirmed to be correct. Is the mandatory erase usual with AS device programming?