ContributionsMost RecentMost LikesSolutionsRe: Altera EP4CE22F17C8N Can't Recognize silicon ID for device 1 HI Fakhrul, Here is how my programming goes: Info (209060): Started Programmer operation at Tue Apr 18 09:06:50 2023 Info (209016): Configuring device index 1 Info (209017): Device 1 contains JTAG ID code 0x020F30DD Info (209007): Configuration succeeded -- 1 device(s) configured Error (209025): Can't recognize silicon ID for device 1 Error (209012): Operation failed Info (209061): Ended Programmer operation at Tue Apr 18 09:07:07 2023 Our customer provided us with a PC to do the programming and test, so I don't have a say in updating to the latest Quartus, but I am using Quartus II version 12.1 build 177. This is what my programming environment looks like: The KDB "Error: Can't recognize silicon ID for device 1" looks like my same error but I don't have a separate connector to program the EPCS device directly. Is the only other possible problem a noisy TCK? Altera EP4CE22F17C8N Can't Recognize silicon ID for device 1 We have build a lot of these assemblies and this board is a one off problem board. When I try to program this device in Quartus, I get the error "Can't Recognize silicon ID for device 1". I have checked the crystal and swapped out the EEPROM. We had this part replaced by a company that x-rays and specializes in BGA rework. I want to be able to verify everything else works before replacing this Cyclone again. What would cause this error? What is the minimum surrounding circuitry needed to program and recognize silicon ID? Re: Cyclone III Programs, Doesn't Boot I have no response because you haven't added anything to this thread. I was hoping that you would have a more in-depth insight to a possible problem outside of basic troubleshooting steps. Yes, it is possible for someone to take an FPGA off of a good working board and put it on a non working board. However, there is a lot of room for error in there. During removal, we could wreck the FPGA. During the placement of the known working one, we could wreck the FPGA. Even if we didn't wreck the FPGA, we could still have issues with BGA balls not soldered. The many possible errors during the removal and replacement make this troubleshooting step very questionable and if the board still didn't work, I would still be questioning the FPGA. Are there particular signals that make it possible for Quartus to say it programmed successfully but will not run? Re: Cyclone III Programs, Doesn't Boot I'm sure it is possible but sketchy at best. We don't have the capability to re-ball these BGA parts. So even if we had a known working board and wanted to borrow the FPGA, we wouldn't be able to re-mount the donor FPGA. Not to mention, I would worry about damage of a good working board and a good working FPGA. Re: Process of Programming Kills FPGA What do you mean by checking the signal integrity of the board? Are there particular signals that I should look at because there are a lot of signals on the FPGA? I don't have another USB blaster to try but I am able to program other boards including the board I mentioned that was previously dead and now operates fine. Re: Cyclone III Programs, Doesn't Boot The USB blaster appears to be fine. I can successfully program other boards without problems, including other boards exactly like these two. I'm not setup on other computers yet but I could try that. Since I am able to program other boards on that programming computer, I don't feel like it is a PC problem either. These boards did not work previously. These were assembled and failed to boot during test. After they failed, we have inspected the boards for irregularities, reflowed the BGA package FPGA, and replaced the FPGA. Nothing to this point has worked. Re: Cyclone III Programs, Doesn't Boot I used Quartus 12.1 to program with an Altera USB Blaster. I forgot to mention that this problem is unique to these two boards. I don't think programming setup it wrong because we have programmed many of these boards without issue. The two boards that I am looking at are outliers that I would like to get working. Our customer did the design and firmware. We produce, program and test these boards. Are there any signals that the FPGA needs to load and run the image from flash that isn't needed while programming? I am mostly wondering about possible hardware issues with bad parts and bad connections. Re: Process of Programming Kills FPGA Hi Bruce, This is a custom board that one of our customers designed and initially tested. We manufacture, program and test these units. Then ship them finished units. We have been making these for years and have come across this problem in the past but haven't had a chance to look into it until recently. We still have plenty of success but want to increase the yield. We only have one image to put on the FPGA and when I tried Quartus told me that it couldn't access the JTAG chain. So I wasn't able to load the image and the FPGA does nothing. Thanks! Cyclone III Programs, Doesn't Boot I have two boards with Cyclone III FPGAs that appear to program and verify properly but it doesn't boot. It has activity LEDs that turn on, showing that it is doing something but not operating as it should. It also has a buzzer that should beep on boot and an ethernet connection but neither are working. What could be happening where an FPGA could be programmed properly but not load from the memory and boot? Process of Programming Kills FPGA We have had some instances where programming an FPGA appears to kill the FPGA. For instance, we had two boards that has a Cyclone III and wouldn't program because Quartus said it couldn't access the JTAG chain. We measured low resistance on the programming header. Then we removed the FPGAs and found that the low resistance was gone. Then we replaced the FPGAs and the low resistance was still gone. However, the first one I tried to program came up with the same error and the programming header had low resistance again (6 ohms on the TMS signal). The second one programmed properly. We are using the power supplies on the board to power and they look clean. We are using an Altera USB blaster to program. Unfortunately I didn't measure for low resistance right after powering the board and before programming but I will after we replace the Cyclone III again. What in the process of powering and programming the board could kill some FPGAs but not others?