- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a custom board with a Cyclone10LP and EPCQ64-A configuration flash. The custom board is similar to the setup for our development board the Cyclone10LP Evaluation Kit using the part 10CL025YU256I7G. The Evaluation Kit shipped with an EPCQ128-A that could be successfully programmed via the Factory Enhanced SFL loaded to FPGA over JTAG header. Though, there were intermittent returns of the "Can't recognize silicon ID for device <name>" error here. Erasing the flash memory first seemed to alleviate this.
Using the same stock SFL, our custom board will not allow programming of the flash as the Programmer always resulted in "Can't recognize silicon ID for device <name>". Of course, the .jic was updated for the specific EPCQ64-A the custom board uses.
In hopes of a bad chip on the custom board, the configuration flash memory chips for the Evaluation Kit and the custom board were swapped. The devices have the same 16pin footprint. Unfortunately, the custom board still returns the silicon ID message even with a previously tested EPCQ128-A flash being utilized. Additionally, the Evaluation Kit board now suffers the same problem, and cannot seem to upload to flash via the SFL to the EPCQ64-A device.
I am not sure if these chips were somehow fully erased, perhaps overwriting the silicon ID? Is this even possible?
Why doesn't the "Disable EPCS/EPCQ ID Check" option seem to affect the reading of silicon ID? Are the EPCQ-A devices not captured under this option?
In the end, how do I go about debugging the cause of the "Can't recognize silicon ID for device <name>" error?
Any tips or advice is welcomed as I am now stuck with two boards with no configuration flash. I have ordered new EPCQ64-A chips to test with factory configurations but figured I would reach out here before proceeding with my possibly incorrect process of programming the configuration flash. I am using the process specified at https://www.youtube.com/watch?v=dPSFCGNQOCU. A process that worked originally for the Evaluation Kit board.
The MSEL pins have been verified to be set for Active Serial configuration @3.3V. I have used both the USB Blaster and USB Blaster II for programming. Also, development environment is Quartus Prime Lite 20.1 on Ubuntu 18.04.
Thank you for your time!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi TJLW,
Have you tried to use the Quartus standard version 18.1 or 19.1?
Regards,
Matt
![](/skins/images/B7BA37F9CE4B52FF7CAE1FB0388839C8/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