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