- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is weird. So is the MAX10 working as intended after the first configuration?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From your explanation, it seems like the device is broken after several times of programming.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/7FC17B7B85029576C25F1E43CE255B51/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page