AS controller 'override' from NIOS

[Altera_Forum]

Hi, 

 We have gotten into a bit of a mess here and need some Altera Guru help!!! We have inadvertently programmed a large number of boards, many of which are in the field, with an incorrect configuration flash image. Doh!   The bad image concatenates the sof for the master FPGA (AS config mode) with an additional SOF, intended for a second FPGA (PS config mode) that we use on a different product, but which is not present on this board. However, because the first sof in the data-stream contains an image for the device that IS present, it configures correctly, conf-done goes high, and it appears that the hardware is working perfectly.  The problem arises when we then try to update the flash via the NIOS (using EPCS flash controller) it does not work because the Nios cannot open the device. It looks like the AS controller still has control of the SPI pins, presumably because the configuration stream has not technically finished (it contains an image for another FPGA which is not present).  To prove this point, we can manually hold the conf done pin low for a second or so after power-up, and all is well – I assume that the master device simply keeps clocking data and eventually whatever it is that’s counting has had enough and lets go??)  So the big question is this....  is there any way (atera 'legal' or otherwise) to force the as controller into letting go of the spi bus so that it can be accessed from the nios?   I note that the EPCS control registers are undocumented – is there any way I could twiddle bits in the NIOS code to wrest control of the flash from the config logic? I know that using a Quartus JTAG programmer does the job, but that is no good for units in the field.   Any info would be appreciated!!  Thanks.

[Altera_Forum]

--- Quote Start ---  The problem arises when we then try to update the flash via the NIOS (using EPCS flash controller) it does not work because the Nios cannot open the device. It looks like the AS controller still has control of the SPI pins, presumably because the configuration stream has not technically finished (it contains an image for another FPGA which is not present).  --- Quote End ---  I don't think the AS controller ever prevents Nios from accessing the flash via the EPCS controller. The SOF file has a header indicating it's total length. The AS controller will not attempt to read past the end of the first SOF. I would guess there is something else you are doing wrong which stops you from opening the EPCS device from Nios.

[Altera_Forum]

the problem arises when we then try to update the flash via the nios (using epcs flash controller) it does not work because the nios cannot open the device. 

 We have a board that uses this same type of configuration and have not seen this type of issue. If the Nios executable is "running" you are past the AS stage. It's quite possible that the PS load of the 2nd FPGA(performed by the FW) is never completing and looping infinitely on trying to load the 2nd FPGA. The PS load could of course have the EPCS device open, preventing other accesses.

[Altera_Forum]

Hi msardip, 

How do you boot the Nios? Does it also boot from epcs? In this case I think there can not be a hang problem with epcs controller; you say the original application can actually be loaded . This would mean the AS controller has completed the fpga configuration step and it has released epcs control to Nios bootloader. But probably you boot Nios in different way than epcs, otherwise the manual trick with conf done pin doesn't make sense to me.

[Altera_Forum]

Hi Guys, 

 Thanks for the replies.  The NIOS firmware is loaded into SDRAM via PCI and then enabled. We only use ECPS to remotely update the configuration file stored in flash.  It looks like the configuration hardware has two independent mechanisms which is the root of the problem here. One which is in charge of clocking data from the flash file (presumably counting the amount of data based on the header it got from the SOF file) and another piece of hardware which is deciding when the FPGA has enough data to configure itself and enter user mode.   If ever the two mechanisms don't agree, it looks like the thing can get stuck. i.e. the device enters user mode but the AS controller is not finished.  I don't think there is a way out but to recall boards and re-program them.... :(