Forum Discussion

sleh's avatar
sleh
Icon for New Contributor rankNew Contributor
16 days ago

Avalon-ST configuration with Agilex 3 fails

Hi,

I have implemented a kind of passive serial programming from a CPU using SPI and a shift register. The signals nSTATUS, nCONFIG, CONF_DONE, READY, and VALID are directly controlled by GPIOs. This works well except after a power cycle. After the system has powered up, the programming fails — CONF_DONE does not go high. All retries afterward succeed. I already went through the debugging guidelines but couldn’t find an issue. However, I have observed two things:

  • The nSTATUS pin follows exactly the timing of the nCONFIG pin during the first attempt. Normally, nSTATUS is delayed and goes high later.
  • The CPU must finish the complete programming cycle before retrying; otherwise, the FPGA remains stuck in this erroneous state.

I recorded some curves with a logic analyzer:

  • full_timing.png:
    1. Power cycle
    2. First configuration cycle fails
    3. Retry works
    4. Another cycle also works
  • 2_start.png:
    • Beginning of cycle 2. Here, the nSTATUS pin follows exactly the timing of the nCONFIG pin.
  • 2_3_restart.png:
    • End of cycle 2 and beginning of cycle 3.
  • 4_start.png:
    • Another configuration cycle that works.

Any idea what could cause this problem?

Regards Samuel

Configuration
Programmable Logic Device

14 Replies

    • sleh's avatar
      sleh
      Icon for New Contributor rankNew Contributor
      16 days ago

      Let's hope it works this time.

      • sleh's avatar
        sleh
        Icon for New Contributor rankNew Contributor
        10 days ago

        I checked the power-up sequence again and made sure that no input is driven when the power is turned on. I have no idea what could be causing the programming problem.

        Please help, Thanks

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    9 days ago

    Hi Samuel, 

    maybe I missed something, but I don't see signal names for LA traces.

    Also post #1 is talking about PS configuration method while you later mention AVST.

    Regards Frank

    P.S.: Sorry for confusion. My image viewer cut left margin. 

    What is the criterion for deasserting valid at the end of failing cycle?

    • sleh's avatar
      sleh
      Icon for New Contributor rankNew Contributor
      9 days ago

      Hi Frank,

      We have been using Cyclon and Agilex FPGAs for many years. These are programmed via PS from the host CPU using SPI. Unfortunately, Agilex does not support PS, and we do not want to use an additional CPLD or QSPI flash for configuration. Therefore, I am trying to emulate a kind of passive serial programming based on AVST, see attached image.

      The programming generally works, but fails the first time after power-up. I suspect that there is a problem even before programming, as the nSTATUS pin follows the timing of nCONFIG, which is unexpected, see attached image.

      • FvM's avatar
        FvM
        Icon for Super Contributor rankSuper Contributor
        9 days ago

        Hi Samuel,

        thanks for the schematic, I got the idea of AVST Emulation now. Can't say if undelsyed nSTATUS indicates faulty behaviour, the delay might simply depend on previous device state and be different for first configuration after POR. Seeing neither CONFIG_DONE (config success) nor nSTATUS (config error) asserted means primarily that the device is waiting for more data, I think.

        Regards Frank

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    8 days ago

    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

    • sleh's avatar
      sleh
      Icon for New Contributor rankNew Contributor
      5 days ago

      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_altera's avatar
        FakhrulA_altera
        Icon for Regular Contributor rankRegular Contributor
        1 day ago

        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

         

  • sleh's avatar
    sleh
    Icon for New Contributor rankNew Contributor
    1 day ago

    Hi,

    I also measured the power-up sequence. All measurements were triggered at the supply voltage. The time refers to the 0.75-volt rail. Is something wrong here?

    Best Regards
    Samuel