I have a Cyclone V design (5CSEBA5) that I am trying to configure using a EPCQ128 deviceI have created a .sof file that I can load into the FPGA directly (Jtag USB Blaster) and it works fine (blinks my user debug LED) I have tried to take that same .sof file and create the file to program the EPCQ128, but I am not sure I am going about this the right way. I used the "Convert programming file" program with the following settings Programming File Type = Jtag Indirect Configuration file Configuration device = EPCQ128 Mode = Active Serial x 4 File name = output_fille.jic create memory file and create config data boxes are NOT checked under "input files to convert" there are: Flash Loader 5CEBA5 SOF Data romulus.sof The romulus.sof file is the same one that I can load directly and get my blinking LED I generate the file, then use the stand alone programmer. I autodetect the FPGA, then "attach" the EPCQ128 In the box for assigning the files I select the EPCQ128 and "change" the file (I discovered that you MUST change the file, not "add"!) to point to the jic file just created. I check the box for programming the EPCQ128 and click start. The FPGA programs with the "factory default SLF" image and the it erases and programs the EPCQ128. I can verify the EPQC128, so everything looks okay. But then I power cycle and expect the FPGA to configure from the flash device, but it fails. I have the MSEL[4:0] pins set to 10011 (standard active serial). I have also tried 10010, for FAST AS. I can probe the pins on the EPCQ128 and I see: DCLK is going at about 80 MHz. nCSO is mostly low, with a short pulse high every 175ms The four data pins are toggling The nCE pin to the FPGA is tied low NCONFIG and NSTATUS are pulled high (10K) - (addition: Nstatus does get asserted low every 175 ms) Config_done drives a FET which in turn drives an LED. This circuit works as expected when I program the FPGA directly via JTAG I figure that the basic JTAG connection to the FPGA is okay as I can configure it directly and it appears I can program the FLASH device through it. The connections between the FPGA and serial FLASH device appears to be proper because I can program and verify the FLASH I am suspecting that I didn't create the .jic file properly but I don't know what to do different. I am using a .jic file because that is the only format that the programmer will allow me to select for the file that will get programmed into the attached flash device. I would really appreciate any help here! Rod
Hi Rod, Try with below options Tick memory file check box while generating .jic file.(To generate output_file.map) The .map file contains starting and ending addresses for boot code, configuration page data, and application code. Or 1.Check the pin nConfig and nStatus in reset state it should be high state. 2.Is it development board/custom board?
If you can configure your device via JTAG then there is no problem with any of the device's configuration pins - nCONFIG, nSTATUS, nCE, CONF_DONE, INIT_DONE. So, you can ignore these.I suspect, like you, you're creating your .jic file incorrectly. Refer to "how do i create a jtag indirect configuration file (.jic) file with my nios ii hardware and software image? (https://www.altera.com/support/support-resources/knowledge-base/solutions/rd10132010_126.html)". You can ignore steps 1 to 3 and 11, they're required if you want to boot your Nios software from EPCS too. Start at line 4. Ignore the references to map & hex files in step 12. You should then be able to select your .jic file from within the Quartus programmer and configure your device. Cheers, Alex
I have (hopefully) attached a screen shot of the Convert Programming File setup that I used. I am not seeing the attachment in the "preview" but it says it is attached so maybe it will appear.--- Quote Start --- Try with below options Tick memory file check box while generating .jic file.(To generate output_file.map) --- Quote End --- Okay, this is what the map file says: BLOCK START ADDRESS END ADDRESS Page_0 0x00000000 0x006AEBCF Configuration device: 5CSEBA5 Configuration mode: Active Serial x4 Quad-Serial configuration device dummy clock cycle: 12 Notes: - Data checksum for this conversion is 0x99FF6008 - All the addresses in this file are byte addresses --- Quote Start --- 1.Check the pin nConfig and nStatus in reset state it should be high state. 2.Is it development board/custom board?
Hi Rod, 1.Can you try by selecting Memory Map File check box (which is checked by default Don't Change). In .JIC file we already have/integrated serial flash loader so that it can communicate to flash. In .pof file we don't have serial flash loader, So we need to create serial flash loader and load(.sof) first. and then program .pof. Refer below link for the flash programming https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/an/an370.pdf Best Regards, Anand Raj Shankar (This message was posted on behalf of Intel Corporation)
--- Quote Start --- 1.Can you try by selecting Memory Map File check box (which is checked by default Don't Change). --- Quote End --- As I mentioned above, I did click the box to get the map. See the text in blue from my previous post. Would checking this box have any effect other than creating the map file? I have NOT tried programming the FLASH since I created the map file. --- Quote Start --- In .JIC file we already have/integrated serial flash loader so that it can communicate to flash. In .pof file we don't have serial flash loader, So we need to create serial flash loader and load(.sof) first. and then program .pof. --- Quote End --- I will give that a try. Unfortunately, I am about an hour away from where the prototype system is so I can't just go run into a lab and test it quickly. I will drive over there later this afternoon and try this out. Rod
I'm concerned you have a signal integrity issue. Everything you're doing is correct. Are you confident it'll run at 80MHz? nSTATUS (and nCONFIG?) being asserted every 175ms is consistent with it restarting - in x4 mode at 80MHz your device should have completely configured in that time. So, this seems to be a new attempt being made by the FPGA to configure.You could monitor nSTATUS. If this ever goes low during delivery of the configuration data it indicates an error. (Note: nSTATUS also follows nCONFIG low at the start of the configuration cycle.) Try slowing the configuration clock (DCLK) frequency - reduce it to minimum. "altera enhanced configuration devices (https://www.altera.com/en_us/pdfs/literature/hb/cfg/ch_14_vol_2.pdf)" discusses this and shows how this is done. Cheers, Alex
Anand : I tried using .jic files created with the "Memory Map File" box checked. No difference.I also tried all combinations (4) in the "advanced" settings for "Disable ID check" and "Disable Error Check". No difference in operation Alex: I originally had the MSEL pins set for "FAST" mode of Active Serial. I tried changing it to Standard mode and now the clock rate is ~40 MHz. No difference in the operation. I am not aware of any way to slow it down below that. I am using the "Active" serial mode, not the passive so I don't have the options that the "Enhanced" devices offer. Can anyone tell me what the significant difference is between the EPCQ128 and EPCQ128A FLASH parts are? I am using the 'non A' version, should I try the A? Rod
Refer to the 'DATA Clock' paragraphs of the 'Active Serial Configuration' section in the "cyclone v device handbook (https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/cyclone-v/cv_5v2.pdf)" - page 7-18.--- Quote Start --- you can choose a 12.5, 25, 50, or 100 MHz clock under the Device and Pin Options dialog box, in the Configuration page of the Intel Quartus Prime software. --- Quote End --- The FPGA always initially clocks at 12.5MHz until it reaches a particular point in the bitstream where, if indicated, it changes to a faster speed. Cheers, Alex
okay, I have tried it with the clock speed set to 12.5 MHz. The DCLK frequency is now 9.8 MHz.It still doesn't configure. As I understand it, the FPGA must be reading at least some of the configuration data, otherwise it wouldn't have kept the clock rate at the lowest setting. Is there any way to establish how far it gets before a problem occurs? Rod
The data stream could be erroring. In which case you'd see nSTATUS going off early. You can calculate how long it should take to configure given the image size, configuration clock speed and config data width. If nSTATUS goes off before it's finished you have an error.I'd also question the integrity of the power rails. Is something else switching on whilst the FPGA is configuring, causing one of the rails the FPGA depends on to dip? This might cause the FPGA's configuration state machine to reset and start again. Is something happening 175ms in, when you said nSTATUS is asserted low? If this was still happening having reduced the configuration clock speed it would indicate it's not necessarily FPGA related. Cheers, Alex
--- Quote Start --- I'm having the same problem, did you resolve this? --- Quote End --- Yes. It turned out to be a circuit problem: I didn't have a pull-up on the config_done signal. Once I added the pull up everything worked properly.