Forum Discussion
Hi Samuel,
I agree with your considerations, that the configuration cycle in your recording seems to proceed irregular.
I wonder if the behaviour may be caused by an unwanted nCONFIG assertion at 1 (power cycle).
Regards
Frank
- sleh1 month ago
New Contributor
Hi Frank,
nConfig is connected to VCCIO_SDM via a resistor, therefore nConfig follows the VCCIO_SDM rail when the power supply is turned on. As a test, I pulled nConfig to low, see attached image. Unfortunately, the behavior is still the same, the first cycle fails.
What can I check next?
Regards
Samuel- FakhrulA_altera1 month ago
Regular Contributor
Hi Sleh,
Thank you for sharing the timing captures and details.
From your description, the key symptom is that during the first configuration attempt after power‑up, nSTATUS follows nCONFIG exactly. This usually happens when the FPGA is not yet ready to accept configuration data. After the first failure, all later attempts work, which supports the idea that the internal configuration logic is only ready after a short time delay.
Based on this behavior, it is worth to check this KDB: https://community.altera.com/kb/knowledge-base/why-does-configuration-fail-to-recover-after-unsuccessful-initial-configuration-/343475
Here are a few things you can try:
1. Add a delay before starting the first configuration after power‑up. For example, wait 10–50 ms before driving nCONFIG low.2. Check all power‑on timing and ensure the rails are stable before pulling nCONFIG low.
3. Verify pull‑ups on nSTATUS, CONF_DONE, and nCONFIG, since weak pull‑ups can cause the first cycle to fail.
4. Make sure there are no glitches on nCONFIG during power‑up.
5. Ensure the CPU always completes the full configuration cycle, even in the failed case. Incomplete cycles can leave the device in a stuck state, as you already observed.
If adding a delay before the first cycle improves things, that would confirm that the issue is related to power‑up readiness.
Regards,
Fakhrul- sleh28 days ago
New Contributor
Hi Fakhrul,
Thank you very much for your suggestions.
>This usually happens when the FPGA is not yet ready to accept configuration data.
Since the programming is handled by a CPU, it takes about 10 seconds to start.We have moved the programming from the user space to a Linux driver. This has significantly increased the programming speed. The issue has been resolved since then. It appears that the problem was related to a maximum time limit.
Regards
Samuel