Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

Arria II. Load Image with FPP Protocol. Nstatus stuck low ?!

Hello.

I have an FPGA board with an Altera II connected to a Cypress bridge.

I have written a firmware for the bridge in order to load the FPGA image with the FPP protocol (all 4 MSEL low).

The first step does not seem to work actually.

here is the issue:

I set nCONFIG high for ~200ns. then low for 50ns, and high again.

The FPGA seems to reset: nSTATUS is pulled low less than 1ns after nCONFIG, and comes back high after ~300ns.

first issue: CONF_DONE does not change however, and stays low. the pin is pulled by a 10k resistor to 2.5V. I have actually never seen it moving, and yes I am probing the good pin.

second issue: INIT_DONE does not change either.

after the init phase described above, I send DCLK and DATA[7:0] (MSB>LSB ).

INIT_DONE stays low the whole time. I have never seen that pin change status either.

third issue: during the middle of the data sent, nSTATUS goes low, and stays low until the end of the transmission...

this is weird. I would have thought that only nCONFIG would affect nSTATUS. apparently not. nCONFIG stays high the whole time, but nSTATUS decides to go low at a certain moment. and does not come back high at any moment.

would anyone have an idea of where the issue could be ?

is there any other pins I could probe to get more information about the FPGA state ?

thanks a lot,

edit: I gathered more information on the issue and continued on the following topic: http://www.alteraforum.com/forum/showthread.php?t=42667

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    thanks for your reply.

    I have checked more in detail, and nSTATUS actually always goes low between the 62.000th and 62.999th byte.

    I do not have access to a JTAG port for the FPGA, so this is unfortunately the only way I can troubleshoot it.

    thanks for the document, I will have a second look at it
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    I have checked more in detail, and nSTATUS actually always goes low between the 62.000th and 62.999th byte.

    --- Quote End ---

    If its that consistent, then its likely a data format error. The error may have nothing to do with those bytes though, it likely takes multiple clocks internally to check previously loaded data bytes.

    If the error was not consistent, I would tell you to check the DCLK edge signal integrity. If your observations are repeatable, then check whether you are serializing data correctly.

    --- Quote Start ---

    I do not have access to a JTAG port for the FPGA, so this is unfortunately the only way I can troubleshoot it.

    --- Quote End ---

    That was a poor design decision. You should always include the JTAG port.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    If its that consistent, then its likely a data format error. The error may have nothing to do with those bytes though, it likely takes multiple clocks internally to check previously loaded data bytes.

    If the error was not consistent, I would tell you to check the DCLK edge signal integrity. If your observations are repeatable, then check whether you are serializing data correctly.

    --- Quote End ---

    I am sending the LSB on data0 and MSB on data7. DCLK has a period of 18ms, with 50% duty cycle, so I believe all of this is correct.

    the thing that bothers me most is that CONF_DONE never goes high. It is pulled high to 2.5V through a 10kohm resistor, but never released by the FPGA. what does this mean ?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    --- Quote Start ---

    If its that consistent, then its likely a data format error. The error may have nothing to do with those bytes though, it likely takes multiple clocks internally to check previously loaded data bytes.

    If the error was not consistent, I would tell you to check the DCLK edge signal integrity. If your observations are repeatable, then check whether you are serializing data correctly.

    That was a poor design decision. You should always include the JTAG port.

    Cheers,

    Dave

    --- Quote End ---

    yes, the design was bad. unfortunately I will have to deal with it.

    the error is consistent. always between the 62k th packet and 62,999th.

    the INIT_DONE pin stays high all the time. is that normal ? I though it should go low after 3 DCLK periods.

    (I have pulled the INIT_DONE to 2.5V with a 10k resistor)