Disable Device ID check during JTAG Programming

[Altera_Forum]

Hello Community, Altera, Intel, 

 sorry for multiple posts, but i would like to seperate discussions about 125°C Flash Memory.   I would like to use a 125° Automotive configuration flash IC (no matter which manufacturer). I attached this type to a Cyclone IV FPGA just for testing: http://www.mouser.com/ds/2/100/001-98283_s25fl128s_s25fl256s_128_mbit_16_mbyte_25-775474.pdf . I, of course, disabled DEVICE ID Check for jic File generating. But i cannot flash this image to my fpga because the programming tool seems to check the flash id any way:   https://www.altera.com/support/support-resources/knowledge-base/solutions/rd10252015_587.html you may turn on the “disable epcs/epcq id check” option in the convert programming files option when you want to generate programming files which disable the epcs/epcq id check performed by the fpga when it configures from epcs/epcq. this option will not disable the id check performed during programming of the epcs/epcq devices by quartus® prime software.   So, my question is: How can i disable ANY ID Checks so i can use a small automotive 125° flash chip? Is there a special command or option to disable checks during jtag ijc programming?   Thank you very much!  P.S. What is the point any way do disable ID Checks (for flash loaders for example?) but stimm to kill any direct programming feature by AS-Programming when using alternative flash chips (Automotive chips!) ?

[Altera_Forum]

--- Quote Start ---  But i cannot flash this image to my fpga because the programming tool seems to check the flash id any way  --- Quote End ---   Which error do you actually see? Wrong device ID in Quartus programmer?   There would be still the option to write the AS flash by custom logic or external hardware.

[Altera_Forum]

--- Quote Start ---  Which error do you actually see? Wrong device ID in Quartus programmer?  --- Quote End ---    Oh, yes, the typical error message: Error (209025): Can't recognize silicon ID for device 1. A device's silicon ID is different from its JTAG ID. Verify that all cables are securely connected, select a different device, or check the power on the target system. Make sure the device pins are connected and configured correctly. Error (209012): Operation failed    --- Quote Start ---   There would be still the option to write the AS flash by custom logic or external hardware.  --- Quote End ---    Yes, but i would have spend ages for a custom external programmer only to avoid this "artifical software problem". (Maybe it would be easier to switch to an other FPGA brand. But i assume every manufacturer has it's own problems.) Or is there a easy "external hardware" solution? Indeed, i have my own CAN-Bootloader - but this is so slow and i always need a running Microcontroller and CAn Controller and CAN-Bootloader software. No way for fast development.

[Altera_Forum]

I've been searching for alternative AS-Programming devices for some time. There are none, as far as I can tell. "Disable ID check" is useless.

[Altera_Forum]

Maybe you could write your programming data directly to the flash by NiosII to bypass Quartus programming tool? Of course you would need a path like USB/RS232 to download your programming data to FPGA first.

[Altera_Forum]

Getting data INTO the FLASH isn't the only problem. Getting data OUT of the FLASH during AS configuration doesn't work with "alternative" devices. See my recent thread on this subject; https://www.alteraforum.com/forum/showthread.php?t=56762

[Altera_Forum]

--- Quote Start ---  Getting data OUT of the FLASH during AS configuration doesn't work with "alternative" devices.  --- Quote End ---   As stated in your original thread, it did work in the past with other "alternative" devices. In so far the statement is too general, I think.  It's necessary to check in detail why the different devices fail and whether the problem can be fixed or not.  The other point is this. Altera has never been a flash manufacturer, instead they sold rebranded third party chips with large surcharge. Intel stopped making flash memory many years ago. Apart from the price differences that matter in sensitive application, the Altera EPCS/Q chip portfolio suffered from a limited offer of package and supply voltage variants.   Thus there are many reasons to use "alternative" chips as serial configuration devices. The straightforward solution would be to give complete information about device requirements and possibly add support for industry standard flash devices in tools.

[Altera_Forum]

I didn't have time to dig any deeper, what with work to do and a schedule to meet. I had room on the board for the huge EPCQ part, so I just used it.

[Altera_Forum]

--- Quote Start ---  I had room on the board for the huge EPCQ part, so I just used it.  --- Quote End ---   That was also my approach in case of EPCQ256, to be on the safe side and have the Altera device as an assembly option, also in case of a supply bottleneck. But I found out that Micron N25Q256A13ESF worked as perfect replacement. I guess that newer Micron MT25Q256 will work as well, but didn't yet check.

[Altera_Forum]

I worked through serial flash datasheets and think, I've found why the Macronix and Cypress devices fail in configuration phase although they could be correctly programmed and verified as reported by gj_leeson. 

 These chips have non-volatile enable bits for quad SPI mode that must be set once for ASx4 to be operational. Programming and verification by SFL uses single SPI mode, so the problem shows only during FPGA configuration. Micron N25Q256A (the original EPCQ256 chip) and MT25QL256 don't have a quad enable bit.  The best solution would be to write a modified Factory SFL application that sets the quad enable bits for the respective chips. If boot time isn't critical you might try ASx1 mode in programming file conversion.

[Altera_Forum]

Thanks for the insight into this problem. Your proposed solution could be an option down the road.