Forum Discussion

HKana17's avatar
HKana17
Icon for Occasional Contributor rankOccasional Contributor
14 days ago

Cyclone I (EP1C3) Configuration Issues: Sequence and Environment Dependent Failures

Hi, I am aware that Cyclone I is a legacy device, but we are maintaining a long-life product and would appreciate any insights from experienced engineers.

[ Environment and System Configuration ]
I am maintaining a legacy system developed 20 years ago. I am facing inexplicable configuration and boot issues that depend on the programming environment (PC/location) and the sequence of file versions written.

FPGA: Cyclone EP1C3T100C8
Configuration Device: EPCS4SI8
Software: Quartus II 9.1sp2 Web Edition
OS: Windows 7 Professional SP1
Download Cable: Terasic USB Blaster

Setup Locations:
A) Design Office (Me): 2 boards (with JTAG access), PC "A"
B) Factory: Multiple boards (AS mode only, no JTAG), PC "B"

[ Description of Phenomena ]
Phenomenon 1: Spontaneous Mode Change (Factory / 2-year-old board)
In Dec 2025, a board worked correctly. In March 2026, it behaved as if it were in a different operation mode.

Details: The mode is hard-wired within the internal logic and should not transition.
Action: Re-writing the same POF file restored normal operation.
Note: This happened within only a few months of storage.

Phenomenon 2: Failure to Transition from Initial State (Office / 10-year-old board)
A JTAG-enabled board was stored for one year. Now, it fails to function even with known-good files.

Details: Even writing the original SOF that worked in Feb 2025, the FPGA stays in its initial state and fails to perform state transitions.
Quartus reports "Success," but the hardware logic does not execute.

Phenomenon 3: Sequence-Dependent Success (Factory / New 2026 boards)
When writing a Dec 2025 POF to five new boards:

Behavior A (3 boards): Initially stayed in the initial state. However, after writing an older Feb 2025 POF, they started working. Over-writing them with the Dec 2025 POF then resulted in success.

Behavior B (2 boards): Worked perfectly from the first attempt.

Why would a specific version history be required for some boards to work?

Phenomenon 4: Lack of Compatibility (Office vs. Factory)
A POF verified to work when written by Factory PC (B) does not work when written by Office PC (A).

Details: When written by PC A, the board stays in the initial state and fails to transition, identical to Phenomenon 2.

[ Discussion and Questions ]

  1. Incomplete Initialization: Is it possible for the configuration to reach "Done" while internal registers fail to initialize correctly due to power supply slew rates or noise?
  2. Silent Data Corruption: Are there known issues with Quartus 9.1sp2 and Terasic Blasters where bit errors occur during programming without being caught by the verification process?
  3. EPCS4 Residual State: Why would writing an older version "prime" the board to accept a newer version? Could this be related to EPCS sector erase issues?

Since these are legacy devices, any insights would be greatly appreciated.

Regards,
HKana17

Configuration

2 Replies

  • HKana17's avatar
    HKana17
    Icon for Occasional Contributor rankOccasional Contributor
    26 minutes ago

    Thank you, Fakhrul, for your response and for looking into this.

    I would like to provide an update. Just before your reply was posted, I independently identified a flaw in my own logic design—specifically within the state machine implementation.

    The root cause was a side effect triggered by a newly extended specification. To suppress this side effect, I implemented a fix, but I overlooked the fact that it also impacted unrelated operation modes. Because these modes were supposedly unrelated, the bug went unnoticed for a year, making it difficult to trace the cause when the issue finally arose. It was a classic oversight on my part.

    I have since corrected this bug, and I have confirmed that the boards (4 units tested so far) are now performing state transitions correctly as expected. This logic update has resolved the issues described in Phenomena 2, 3, and 4.

    Regarding Phenomenon 1 (the spontaneous behavior change after storage), the cause remains unexplained. While I cannot reproduce it at my office, the factory staff are certain that the failure occurred as described. However, since the board returned to normal operation after a re-write and is currently stable, I have decided to conclude my investigation of this specific case for now.

    As the primary issues have been resolved by the logic correction, I will be closing this thread. Thank you again for your time and support.

    Best regards,
    HKana17

  • FakhrulA_altera's avatar
    FakhrulA_altera
    Icon for Regular Contributor rankRegular Contributor
    1 hour ago

    Hi HKana17,

     

    Thanks for the detailed write-up. With legacy Cyclone I and older Quartus, there are many possible causes here (power, flash wear, board variation, cable/driver differences, programming settings, and more). As written, it is difficult to troubleshoot because it mixes several symptoms across different boards, dates, and environments.

     

    To keep this focused, could you please pick one failing board and one specific failure, then share only the minimum items below?

    1. Which exact file is used (SOF or POF), and the full Quartus version build string
    2. Programming method (JTAG or AS), and the exact Programmer settings used (including verify, erase, compression, and any “auto-detect” results)
    3. The board power-up sequence and whether the FPGA is configured from EPCS at power-up or only after programming
    4. What you observe on key pins if available (nSTATUS, CONF_DONE, nCONFIG), or any LEDs tied to them
    5. A repeatable step list: start condition, program steps, power cycle or not, and expected vs actual behavior

    Without a repeatable single-case report, the best anyone can do is guess. If you can narrow it to one board and one reproduction path, people here can give more targeted advice.


    Regards,
    Fakhrul