Remote update block gives pof_error...

[Altera_Forum]

We have intermittent problems with loading images from EPCS64 flash into stratix III. 

 We us the remote update flow with 'factory' and 'application' images, both compressed, living in EPCS64.  One of our images (with factory and app images identical) gave a 'pof error' when attempting to load app image.  I know what the altera docs say about pof error (it is due to blank, partial, or misplaced design etc). But I can read back the flash and there is no such problem in the images.  So: I need to know what EXACTLY the remote update block checks. Is it just a quick check of the POF header? Which bytes exactly?  If it only checks a few bytes in the header, how then can the documentation claim that it will detect partially configured devices?  Thanks, Nick

[Altera_Forum]

I might be confusing Stratix II and Stratix III here. For the failing POF, does the associated Quartus project have remote configuration enabled in the device settings ... or is it set to local? 

 Jake

[Altera_Forum]

weird - i replied before but i don't see my reply now. 

 We have a scripted flow: set_global_assignment -name STRATIXIII_UPDATE_MODE REMOTE set_global_assignment -name STRATIXIII_CONFIGURATION_SCHEME "ACTIVE SERIAL" set_global_assignment -name USE_CONFIGURATION_DEVICE ON set_global_assignment -name ON_CHIP_BITSTREAM_DECOMPRESSION ON set_global_assignment -name STRATIXII_CONFIGURATION_DEVICE EPCS64  It works normally and is well tested. But if/when we get another failing image, I would like to find out why. And to find out, I need to know what altera check when they declare a "POF_error" in their remote update block.  If they are only reading a few bytes in the header, then which bytes is it? And how would that protect against partially loaded designs? I don't think they read the whole file - it all happens too quickly...