Altera FPGA downloads JIC file successfully, but does not load, downloads sof normally

wsmysyn

Altera FPGA downloads JIC file successfully, but does not load, downloads sof normally [Copy link]

As the title: I was debugging FPGA recently and needed to burn the code into Flash; but the jic file was downloaded successfully but the FPGA loading process could not be stopped and the program did not run. Target chip: EP4CE10F17C8; BGA package Flash: EPCS16, or compatible model quartus version: 18.0/17.0 Background: 1. The core board of FPGA is a ready-made module, and only the jtag interface is left, and the AS interface is not reserved; the core board is configured with EPCS16 flash 2. The ready-made FPGA module is inserted into the floor drawn by itself through the pin header; 3. Usually, when debugging, I always download the sof file, and the logic function is normal. 4. After converting the sof to a jic file and burning the flash, I select verify and config, and it prompts success. Unplug the jtag and power on again. It is found that the config_done pin is always low. The FPGA does not run. 5. Also in the quartus 18.0 version, based on the previous EP4CE6E22C8 development board, the flash model is also EPCS16, and the download of the sof and jic files are normal. Try: 1. All power supplies have been confirmed and are normal. 2. After powering on again, measure the pins of the SPI flash and find that the DCLK, ASDIO, and DATA pins have signals and are in action. DCLK is a 33MHz square wave. So the FPGA has not been loaded? ? It has been like this for several minutes; the so-called stuck? 3. Replace the flash that was verified OK on the development board of EP4CE6E22C8; the same problem occurs; 4. Write a very small lighting program, which only uses two pins; download sof file is normal, download jic file has the same problem; 5. Quartus version has been 18.0 before, and then use 17.0 version to recompile the project and convert jic file; download problem still exists 6. Replace FPGA core board, the problem still exists; 7. Check the configuration mode of MSEL[2:0]; CE10F17 board is 010 mode, "1" is 2.5V; The top of a board CE6E22 I drew myself uses 101 mode, "1" is 3.3V Other special pins such as TMS, TDI, TDO, TCK, config_done, nStatus, etc. are handled in the same way as the previous ok board; Question: 1. Do you have any comments? Has anyone encountered the same problem? How did you solve it? It’s giving me a headache 2. I have a few suspicions now, but they haven’t been verified yet, or they can’t be verified for the time being A: Does the MSEL configuration method have any impact? At least it’s different from the setting method of the EP4CE6 development board I made before; but I’m not sure if it has any impact B: The trace is too long (about 10cm at most), is there a signal integrity problem? Not verified yet; C: There is a problem with the FPGA itself D: There is a problem with the baseboard design E: In addition, the downloader is a compatible series, not the original one; I have a few other versions that I can try\ F: Other things I didn’t notice Attachment: The settings of the flash and jtag parts of the finished FPGA core board module; I think there should be no problem Core board IO location diagram Schematic diagram of the jtag part of the baseboard

cruelfox

When I used Cyclone IV, the problem was that the jic failed to burn (USB-Blaster was not original), but Cyclone III had no problem. MSEL2..0 = 010 had no problem, "1" was connected to 2.5V VCCA "3. Replace the EP4CE6E22C8 development board to verify the OK flash; the same problem; "Put the jic in the OK board, and then solder it to the new board to see? And put a jic in the new board, and then solder it to the old board to see if it can be configured.

wsmysyn

cruelfox posted on 2018-7-29 07:55 When I used Cyclone IV, the problem was that the jic failed to be burned (USB-Blaster was not original), but there was no problem with Cyclone III. MSEL2 ...

I have tried burning jic on an ok board and then switching to a new board, and the problem is the same; I have not tried switching back, but I can try it. Now it seems that there are two more operations that can be tried. 1. Change the downloader to another model and try it; I now have 3 types of downloaders, and I can try each of them. 2. Burn the new board and switch to the old board. I also found a seller, and they sent me a new set and asked me to try it. Let's see what the results are on Monday

constant

sof can be downloaded, FPGA is fine, is there a problem with the configuration chip? If so, try another one. . . . .

coyoo

Can't the core board be powered on and debugged separately? The seller should have debugged it before selling it.

wsmysyn

coyoo posted on 2018-7-31 11:22 Can't the core board be powered on and debugged separately? The seller should have debugged it before selling it

The core board is led out with 1.27 pin headers, which is not convenient for separate debugging at the moment, but the problem has been solved, see below.

wsmysyn

Thanks for your suggestions The problem has been solved now. It was mainly the problem of the MOS tube in the config_done pin part. It may be that the capacitance of the MOS affects the ramp speed, causing this problem. After removing the MOS tube, the configuration can be loaded from the flash normally; but the indicator light cannot be used temporarily.