Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

MAX10 .JBC programming - bogus verify fail errors

I am using MAX10M04DCF256 in an embedded application, programming it via a microcontroller and the Jam STAPL Byte-Code Player.

Everything seems to work, apart from repeatable verify failure errors:

  • So far as I can tell, the actual programming is 100% reliable.

  • If I run repeated attempts at the normal program+verify sequence, then alternate attempts will succeed while the other half report verify failure.

  • The verify failure is always at the very beginning of the verify operation.

  • If I run a separate verify operation immediately after a successful program+verify, it will always fail (and I can repeat it and it will keep on failing).

  • If I run a separate verify operation immediately after a FAILED program+verify, the verify will always succeed (and I can repeat it and it will keep on succeeding)

  • Verify of just the UFM always passes (but another attempt afterwards on the CFM will keep failing or not, whichever state it was in before).

Anybody seen anything like this?

.JBC files are generated from Quartus Prime Lite edition 16.1.2

Byte Code Player is V2.2 (doesn't seem to have changed in 10 years or more!).

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    This 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.
    • RWegg's avatar
      RWegg
      Icon for New Contributor rankNew Contributor
      6 years ago

      I 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?