Info (209061): Ended Programmer operation at Wed Oct 19 16:29:26 2016Įrror: Quartus II 64-Bit Programmer was unsuccessful. Info (209005): Programming status: verify on flash device 1 (Spansion S29GL01GS) Info (209006): Device 1 CFI Flash 1 is Spansion S29GL01GS (16 bits data bus) Info (213045): Using programming cable "USB-Blaster " Info: Command: quartus_pgm -c USB-Blaster C:\Firmware\FPGA_VERIFY. Info: Processing started: Wed Oct 19 16:27:31 2016 Info: devices manufactured by Altera and sold by Altera or its Info: that your use is for the sole purpose of programming logic Info: applicable license agreement, including, without limitation, Info: the Altera MegaCore Function License Agreement, or other Info: Subscription Agreement, the Altera Quartus II License Agreement, Info: to the terms and conditions of the Altera Program License Info: associated documentation or information are expressly subject Info: (including device programming or simulation files), and any Info: functions, and any output files from any of the foregoing Info: and other software and tools, and its AMPP partner logic Info: Your use of Altera Corporation's design tools, logic functions Info: Copyright (C) 1991-2015 Altera Corporation. Info: Version 15.0.0 Build 145 SJ Web Edition Info: Running Quartus II 64-Bit Programmer When running through CMD, I failed with the following response:Ĭ:\altera\15.0\quartus\bin64>quartus_pgm -c USB-Blaster C: \Firmware\FPGA_VERIFY.cdf This method has worked before, but recently, I'm experiencing new trouble where the Flash device would fail to verify whenever I call up the CDF through the CMD line tool (quartus_pgm) but would pass when I open up the same CDF through the quartus programmer. cdf file, which I made using the Quartus programmer. I am currently using the following method to program and verify a CFI Flash device that's not serially on the JTAG chain: ) Any comments would be much appreciated. Good thing my hair is short and I couldn't pull too much out. Definitely was pulling out my hair trying to figure it out. I did notice that Qsys made an adapter for me, and it was at that adapter connection point that the signal would not transmit. I tried forcing a constant 'valid' signal. I triple checked my signals to make sure they were associated properly. I tried the Avalon-ST Error Adapter IP as well as tried writing my own adapter, but I could not drive the valid signal using Qsys. I tried hard to figure this out for three days straight. I was able to solve by exporting both signals and connecting them manually in my top-level instantiation template, but I'd rather have it internally connected. My guess is it that the Avalon-ST adapter that QSYS automatically generates disconnected it. Has anyone else had this issue? Is this a bug? Using SignalTap, I discovered the 'valid' signal of my source would not drive the sink of the TSE module transmit. I tried connecting a custom Avalon-ST source to the Triple Speed Ethernet (TSE) Megacore sink. TSE recieve -> error packet discard module -> additional logic module ->** TSE transmit This does NOT work and valid signal disconnected at point marked by **: TSE recieve -> error packet discard module -> TSE transmit This works as connected in Qsys (Avalon-ST):
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |