Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorCyclone III configuration corrupts image
All,
We have 30 boards with a single EP3c25 wired for JTAG and AS configuration, as per the handbook. Several pairs of eyes have peered at the schematic and the boards and everything looks like it should. But, on most of the boards, configuration with USBBlaster results no errors but a corrupt FPGA image in the chip. Multiple tries will usually result in one good configuration that allows us to program the EPCS. Once that is done the boards work reliably. Except that they are still as difficult to configure through JTAG as ever. The problem varies from board to board. Some are good, some are not so good and others are completely useless. Most of the boards are flaky to useless. All the voltages look good. JTAG signals look clean. The programming software generates no errors. CONFIG_DONE goes high even though the image is bad. (We can tell by LEDs on the board if the image took or not.) We've made Altera and Cyclone III boards before and have not had these kinds of problems. What could possibly be causing this?23 Replies
Altera_ForumCan you probe the INIT_DONE signal?
Look at p56 (these are for PS/FPP, but the signals should do the same thing for JTAG configuration): http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/fpga_configuration.pdf) Note how INIT_DONE goes low when programming starts, and then high again when done on p60. Note how there is a delay between CONF_DONE and INIT_DONE. I wonder if your FPGA is being left in the no-mans land between CONF_DONE going high and INIT_DONE going high. See p63 for enabling the INIT_DONE output. Cheers, Dave- Altera_Forum--- Quote Start --- But, on most of the boards, configuration with USBBlaster results no errors but a corrupt FPGA image in the chip. --- Quote End --- Does "no error" mean, the AS image verifies correctly after programming? P.S.: How do you know, that the image is corrupted? It may be a case of unpredictlable design behaviour as well, e.g. due to asynchronous reset or PLL lock issues. I would activate the CRC output to decide if the image is actually corrupted.
- Altera_Forum
As I understand it, CRC wouldn't help in this case: If the image is corrupted on download, the CRC would be computed on the corrupted image and tell you nothing.
Remember, once the image has been saved into EPCS, we have no problem bringing the board up. It's ONLY through the JTAG that there's a problem. - Altera_Forum
Does anyone know where I can find the information about the sequence of commands that the JTAG issues to configure the chip?
- Altera_Forum--- Quote Start --- Can you probe the INIT_DONE signal? Look at p56 (these are for PS/FPP, but the signals should do the same thing for JTAG configuration): http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/fpga_configuration.pdf) Note how INIT_DONE goes low when programming starts, and then high again when done on p60. Note how there is a delay between CONF_DONE and INIT_DONE. I wonder if your FPGA is being left in the no-mans land between CONF_DONE going high and INIT_DONE going high. See p63 for enabling the INIT_DONE output. Cheers, Dave --- Quote End --- I've checked. INIT_DONE toggles and goes high at the end, as it's supposed to.
- Altera_Forum--- Quote Start --- I've checked. INIT_DONE toggles and goes high at the end, as it's supposed to. --- Quote End --- It sounds like the FPGA likes what it is receiving then. Did you put any thought into FvM's suggestion - have you synchronized the reset to the clock domains within the FPGA? Have you checked your PLLs are locking ok? I'd recommend putting a SignalTap II instance into the design. Then download and let Quartus communicate with the instance. If it can communicate, then you have a design error. If Quartus cannot communicate, then there must be some form of corruption - however its a strange one, since nSTATUS would normally go low in that case. Cheers, Dave
- Altera_Forum
First, there are no PLLs. How would I synchronize a reset? I seems to me that all that is handled by the USB Blaster.
Second, i had the same idea, but to use signal tap requires that I am able to configure a bad board, which is what I can't do. - Altera_Forum--- Quote Start --- How would I synchronize a reset? --- Quote End --- Reset signals from a push-button, external reset supervisor, or from the USB-Blaster interface are asynchronous signals. The reset inputs on the registers within an FPGA have a setup and hold time (called the reset recovery and removal time). If you violate this, then weird things happen. You synchronize the external reset to each clock domain by running the signal through a reset synchronizer circuit. Altera has examples. Cliff Cummings of Sunburst design also has several good papers which discuss the topic. --- Quote Start --- I seems to me that all that is handled by the USB Blaster. --- Quote End --- Nope. If you're using it to program the FPGA, that's all it does. --- Quote Start --- Second, i had the same idea, but to use signal tap requires that I am able to configure a bad board, which is what I can't do. --- Quote End --- Perhaps you can program the image into the boot device and then try connecting? Cheers, Dave
- Altera_Forum--- Quote Start --- As I understand it, CRC wouldn't help in this case: If the image is corrupted on download, the CRC would be computed on the corrupted image and tell you nothing. --- Quote End --- The asumption is wrong. The CRC is compared to a precomputed value. You didn't answer the question about verify. It's also unclear, if you are programming the serial flash through indirect JTAG or AS interface. --- Quote Start --- Remember, once the image has been saved into EPCS, we have no problem bringing the board up. It's ONLY through the JTAG that there's a problem. --- Quote End --- So the image does not verify correctly? In this case it's most likely a problem of JTAG or AS interface signal quality.
- Altera_Forum
Resolution: It turns out that it's a power problem.
Verify: I don't know how to verify. The Verify box in the programming SW is disabled. CRC: That would mean that I have to generate the checksum somewhere? Or is it already there?
