Arria 10 will not load from Micron MT25QU256 PROM

I have verified that the control signals are working properly and I have changed from a compressed file to uncompressed.

Also with the processor disable I can load the FPGA with the SOF file. I am keeping the processor disabled while trying to load from the PROM so there is no chance of interference.

Hi JCass5,

Since you mentioned that you are able to program the Arria 10 with a .sof file, I assume that you are able to use Quartus programmer and a download cable (such as USB Blaster) to program the Arria 10 via JTAG interface. Are you able to program the MT25QU flash device with a .jic file using Quartus programmer? The Quartus Prime v18.1 should have the option to allow users to generate the .jic file for MT25QU for Active Serial configuration. Thus you can test the MT25QU with the standard programming process using Quartus programmer and .jic file. If the Active Serial configuration is successful after programming MT25QU with the .jic file, this indicates no hardware or signal connection issue.

Regards,

Nooraini

Hi Nooraini,

I have already programmed the MT25QU with the .jic file using my USB Blaster. I selected the MT25QU256 as the programming device in the Quartus programming device options and as the target device in the file conversion program. I am using the device in ASx1 mode. The PROM programs fine. It just fails to load the FPGA at power-up.

What I am seeing at power-up is that the A10 reads the PROM status register, reads the device ID registers and then begins a fast read opeation from the PROM. It read about 33 bytes then during the 34th byte the CS to the prom is terminated after 7 bits. Please refer to the scope images in my original post to see the SPI bus transactions.

Can I really use a Micron MT25QU256 device with an Arria10 or do I need to use a MT25QU512 as indicated in some cross reference chart I saw.

Regards,

Jim Cassey

HI Jim,

Please scope the nCONFIG, nSTATUS and CONF_DONE signal when power up after programmed the MT25QU256 device. Is the nSTATUS toggling? Or the CONF_DONE is low all the time?

Did you set the Configuration Scheme to Active Serial x1 or x4 in the Device and Pin option in your project design before compilation? Please make sure the Configuration Scheme is set to Active Serial x1 or x4 mode and then recompile your design.

You mentioned about a cross reference chart. Can you provide the link to this cross reference chart? I'm not sure if I know what you are talking about.

Also, you mentioned about using processor to program the MT25QU device. Can you provide the schematic showing the FPGA<->MT25QU<->processor connection?

Regards,

Nooraini

I've attached the entire configuration block for the FPGA. U19 in the upper right corner is used to disconnect the processor SPI bus from the PROM/FPGA. The signal FLASH_FPGA_EN is pulled low. All the other control/status signals are connected directly to the processor. I have the processor disabled which tri-states those pins. That means that the pull-up/pull-down resistors are controlling the FPGA load operation at power-up. We have also successfully programmed the PROM and verified the contents using this interface.

I needed to get wires attached to the board to do the scope captures. I will get them to you as soon as possible, The nSTATUS line I believe is toggling. I will get more specifics when I can get the scope pictures.

As for the cross-reference table, it was from Micron and I misinterpreted it. I was looking at the A10 SoC line and not the general A10 line. There is one thing I noticed. Micron implies that the MT25QU parts will only work in Passive Serial mode. I'm assuming that Intel has verified that they work in Active Serial mode as well.

Regards,

Jim Cassey

This is the initial power-up cycle. Channel 1 (Yellow) is nCONFIG. Channel 2 (Green) is CONFIG_DONE. Channel 3 (Orange) is nSTATUS. Channel 4 (Blue) is PROM_nCE (chip enable for the MT25QU).

This is the first program cycle from power-up.

This is the ongoing programming cycle.

This is the interval between programming cycles.

Is there anything else I should look at that may cause a premature termination of the programming cycle? A drop / dip in a voltage rail?

Jim Cassey