Remote Update lockup on Arria IIGX

[Altera_Forum]

summary 

 When using Remote System Update on an Arria IIGX, there does not seem to be any way to avoid stalling the device indefinitely in the event of a corrupted or missing application configuration. Any failed update attempt will result in a product return, because it can't be fixed in the field.  detail  I am using an Arria IIGX, and trying to use Remote System Update.  I have Factory FPGA code and Factory Nios code, which I put in by ByteBlaster using the Nios Flash Programmer. I also have App FPGA code and App Nios code, which I load into a spare area of the EPCS using some Nios code and a PC utility I have written myself. The PC utility will be supplied to our customers, so that they can apply updates without a ByteBlaster.  When the App FPGA code and App Nios code are correctly in place, everything works perfectly, and the handover from Factory to App works just as it should.  When the App Nios code is absent or corrupted, my Factory Nios code detects this by CRC checksumming, and does not attempt to transfer control. My PC utility can talk to the Factory Nios code, and use it to program the correct App Nios code into the EPCS. So far, so good.  The problem starts when the App FPGA code is absent or corrupted. My Factory Nios code assumes the App FPGA code is OK, tries to transfer control to it, and configuration fails. According to the Arria II Device Handbook, Ch 9, in the event of an Application configuration error, the Factory configuration should be reloaded automatically.  Unfortunately, this is not what I see, and after looking at the Errata Sheet it seems this is a known bug. The Errata Sheet recommends working around the problem by using the Reconfig POF Checking feature, but this has problems of its own. I ran into the same problem that was experienced by Forum user Chesh in thread 34702. The problem is that ALTASMI_PARALLEL can't be used in conjunction with the Nios II EPCS Serial Flash Controller, which latter I need in order to put my App code into the EPCS in the first place.  My last attempt to break out of the deadlock was to use the watchdog timer. The idea was that if Application configuration failed, the watchdog timer would trigger a reload of factory code. Unfortunately, this didn't work either - and a close rereading of the Device Handbook p.9-60 reveals why: "The user watchdog timer is disabled ... during the configuration cycle of the application configuration. It is enabled after the application configuration enters user mode." In other words, it doesn't work until the very moment when you no longer need it.  Short of abandoning the Nios, and using an external micro to do remote update, is there any way out of this problem?

[Altera_Forum]

You may include a test of the application FPGA code and Nios code on your flash before handling control over from the factory image. 

 Several parameters in the boot record can be checked, for example the device ID and the size of the image. By using the size of the image you should find the start of the Nios software code on the flash and there you may read the length of the Nios code. This you may use to check that the code outside this is erased. It is not a perfect test, but it detects if the flash has been partially programmed. Have not found how to verify checksum of the image on flash without calculating it by myslf and storing it on flash.    I have not managed to find doumentation on the EPCS flash boot records, but some information can be found in the source of the nios bootloader.