Remote Update lockup on Arria IIGX

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?