Problem with Max 10 I've never seen before

[Altera_Forum]

I have an issue with a MAX 10 design. I've never seen this problem before and I am baffled by it. I have down loaded the FPGA image, which includes a NIOS, and user application code to the internal flash memory. I generated a .hex file from the application code and created a combined .pof and programmed the CFM and UFM using the USB Blaster. After programming the device, I can verify the its programmed before and after cycling power. The application will execute after reset has negated while I have the board powered up on the bench. However, after installing the board in the system which it needs to function in. The system will come up and access the board to run its power-on tests. Somewhere in that time, the flash memory will be corrupted or altered in someway where is will not function. I can remove the board and return it to the bench and I can't verify either the CFM or UFM using the device programming tool. The device memory is not blank but it fails to verify. I can reprogram the device again but eventually, the device will suffer from the same problem again. When the board does retain it's configuration, it will function properly and the application runs without any exceptions and will continue to operate as long as it is powered up. This problem doesn't occur everytime and it is occurring on multiple boards of the same design. Any ideas, questions or suggestions? Thanks.

[Altera_Forum]

Hi, 

 Hope this may help you.  FPGA board is powered by the system/unite right, can you check the power supply requirements and its interface between the system and FPGA board once. If possible issolate the System power which is used to power the FPGA board. And power the FPGA board external and use other system interface and check. Check the de-caps or bulk-cap used in power lines(from FPGA board to the System board).  1. Avoid doing hot plugin and plug out? 2. Make sure to erase the flash location before you perform a program (write) operation.  Let me know if this has helped resolve the issue.  Best Regards, Anand Raj Shankar (This message was posted on behalf of Intel Corporation)

[Altera_Forum]

Update on the problem specified above. What I have discovered was there is a command being issued to the nios from our host computer which is requesting a software reset. The software was pointing all the way back to reloading the bsp. And, apparently, when this occurred, occasionally the CFM and the UFM content was being affected and prevented the image to function. For the short term, the nios will respond to the software reset command with an acknowledge character and nothing else. Since having that change made to the software, there have been no more problems with FPGA image being altered. Thanks to Anand Raj Shankar for responding to the earlier post. Even though I looked into all of your suggestions prior to the post. Having additional thoughts are always good.