Forum Discussion

LostCompass's avatar
LostCompass
Icon for New Contributor rankNew Contributor
6 years ago

JAM 2.5 Player for Max 10 FPGA (10M08SAM153) on Intel Aero Compute Board fails to program/erase

I have tried all possible ways to flash the MAX 10 FPGA on Intel Aero compute board using the default embedded JAM Player 2.5 that comes preinstalled on Intel aero-linux operating system. Im following instructions on: https://github.com/intel-aero/meta-intel-aero/wiki/02-Initial-Setup#flashing and https://github.com/intel-aero/meta-intel-aero/wiki/95-(References)-FPGA . On booting the intel-aero-linux I ran

aero-get-version.py

Which gives me :

BIOS_VERSION = Aero-01.00.16
OS_VERSION = Poky Aero (Intel Aero linux distro) v1.6.2 (pyro)
FPGA_VERSION = 0xff
Aero FC Firmware Version = unknown

The command I am running to flash the fpga is:

#jam -aprogram /etc/fpga/aero-compute-board.jam

The jam file comes installed on the aero-linux under /etc/fpga/ directory. After the first successful attempt, every other attempt since then has failed right at the beginning and has never proceeded to flashing the CRM0. I dont know what might be the reason behind this.

One of the error messages is:

Jam STAPL Player Version 2.5 (20040526)
Copyright (c) 1997-2004 Altera Corporation

Device #1 IDCODE is 031820DD
full-chip erasing Max 10 FPGA device(s) ...
Device programming failure
Exit code = 10...Device programming failure

I know the device doesnt have hardware continuity problem and the JTAG connection is successful as it passes the BLANKCHECK, READ_USERCODE & CHECK_IDCODE actions:

$jam -acheck_idcode /etc/fpga/aero-compute-board.jam

Jam STAPL Player Version 2.5 (20040526)
Copyright (c) 1997-2004 Altera Corporation

Device #1 IDCODE is 031820DD
Device #1 IDCODE is 031820DD
DONE
Exit Code = 0... Success

With the current state the FPGA is in, I always get 0xff for every fpga register register on an spi_xfer command. Is there a way to hard reset the FPGA?

Any help would be greatly appreciated. Thank you

7 Replies

  • YuanLi_S_Intel's avatar
    YuanLi_S_Intel
    Icon for Regular Contributor rankRegular Contributor
    6 years ago

    This is weird. So is the MAX10 working as intended after the first configuration?


    • LostCompass's avatar
      LostCompass
      Icon for New Contributor rankNew Contributor
      6 years ago

      It worked fine for the first 2 configurations. Then it just started failing. Also when I query the FPGA through the following command on the Intel-Poky linux:

      aero-get-version.py

      It gives me back 0xFF for the FPGA version. Whereas before it was 0xa1.

      Using spi_dev to read an FPGA GPIO register (address:0x49) via the SPI bus also returns 0xFF everytime. So it appears the registers are reset to all 1s somehow.

  • YuanLi_S_Intel's avatar
    YuanLi_S_Intel
    Icon for Regular Contributor rankRegular Contributor
    6 years ago

    From your explanation, it seems like the device is broken after several times of programming.


    • LostCompass's avatar
      LostCompass
      Icon for New Contributor rankNew Contributor
      6 years ago

      Is that even possible? How can programming a device multiple times using the same jam file break it. The rest of the Aero board is still working so do you mean its just the FPGA memory that is the issue?

      Is there a brute force way to factory reset the FPGA? By grounding a pin or something?

      Would really appreciate some help as my research depends on it.

  • YuanLi_S_Intel's avatar
    YuanLi_S_Intel
    Icon for Regular Contributor rankRegular Contributor
    6 years ago

    Hi,


    After several discussion and investigation with internal team, it seems like the programming failure is due to the JAM file itself. The reason you obtained 0xFF is because the FPGA is blank. I think there is no failure on hardware.


    A quick check with you, are you programing the correct JAM from correct directory? I check with the documentation, seems like the JAM file is aerofc_compute_board_only_fpga.jam and it is located in etc/ instead of etc/fpga


    Thank You


    • LostCompass's avatar
      LostCompass
      Icon for New Contributor rankNew Contributor
      6 years ago

      Hi, Thank you for following up on this issue. Its very important for my research and so I really appreciate you getting back to me.

      To answer your question, yes indeed. I am pretty sure the jam file is not the issue since I have a spare Aero Compute Board and programming the FPGA on that with the same Jam file gives no problems.

      Could it be that the FPGA can brick some other way? e.g. if in any one of the program-erase cycles, the process was interrupted via a Ctrl+C command by mistake or if the JAM file's configuration was for a different FPGA board type? Going through all the online documentation, tells me that in such cases the programming would fail but would yield a success the next time a jam file with the correct configuration is used that matches the FPGA hardware spec. But in my case it doesn't at all yield a successful programming cycle even when I use a verified jam file provided by Intel: aerofc_compute_board_only_fpga.jam

  • YuanLi_S_Intel's avatar
    YuanLi_S_Intel
    Icon for Regular Contributor rankRegular Contributor
    6 years ago

    Its hard to determine at this point. Based on our discussion, it could be due to programming file problem, configuration pin shorted / FPGA bricked (thus causing FPGA is not able to be programming).


    I would suggest to go for the vendor for any warranty and etc possibility.