Honored Contributor
Honored ContributorThis seems related to another oddity: although I have Quartus Prime configured for a single device - MAX10M04DCF256 - and the 'DCF' means I should only have one sector of UFM available (CFM0 used for single image, CFM1/CFM2 not available on 'compact' variants and UFM1 doesn't exist on the 10M04, leaving just UFM0), the programming file by default is programming sectors 2,3,4 all as UFM (plus the CFM0 in sector 5). I'm not sure what it is putting in there, since my design doesn't currently use the UFM at all.
If I configure the programming tool to omit the UFM (do_bypass_ufm=1), then the verify fail problem doesn't seem to occur - even though it was the CFM that was being reported as failing verify.
New ContributorI have recently encountered very similar behavior when trying to program + verify a 10M04SCE144C8G. It seems like every alternate attempt to program the device in my system using the JAM player (.jbc file created using the quartus_cpf command line tool) it fails. It fails immediately upon starting the verify stage. However, in my case, the program seems to have actually failed as the device does not operate. A subsequent attempt to program in the same manner is always successful. This alternating pattern of failure and success appears to continue indefinitely.
I was originally attributing this to the FPGA's operation somehow interfering with the programming process, thus causing the programming to fail. Subsequently, since the program didn't take, then FPGA operation would not interfere and the next attempt would work.
This theory seemed a little flimsy to me, so I began to search for others with similar problems. I am very surprised to see this question asked. But I'm disappointed to see no answers after so much time has passed? Is there any resolution to or explanation for this issue?
