Troubles while configuring Flex 10K20TC144 in PS mode from microcontroller

[Pierre95]

Hello,

I am trying to configure Flex10K20 from a PIC MCU using 1 bit passive serial mode.

The .rbf configuration file I get from quartus is exactly 28941 bytes in size. It is programmed into PIC's internal Flash and sent to FPGA upon each power on. After sending all 28941 bytes, starting each byte with LSB, I don't see CONF_DONE go high. 

However, while monitoring nSTATUS it goes low for 2µs, after 58ms following the start of sending data serially into the FPGA. The whole process of sending all 28941 bytes lasts arround 200ms.

The fact that nSTATUS goes low for 2µs does it signify an error within the configuration process? Is nSTATUS not expected to stay low for the whole remaining configuration process?

On what criteria does the device determine the configuration went wrong? Is the data checked on the fly? Shall all 28941 bytes be sent to have CONF_DONE go high? 

What could cause nSTATUS go low after 58ms, a wrong byte in the configuration file at this point?

In the design INIT_DONE is left unconnected (as there is no need in PS mode to poll for it).

Thanks a lot for helping me.

[WZ2]

Hi there,

Don’t worry~

Firstly, answer your question:

1.      The nSTATUS just be derived to low after POR, then it goes back to high. In normal conditions nSTATUS follows nCONFIG. By the way, is there week pull up in your design?

And there are the points I don’t understand:

1.      The rbf file is used to config the fpga or Flex?

2.      Is these hardware setting has been checked?

3.      Have we test the config file in the other type like sof?

[Pierre95]

Hello,

Thanks for your answer.

About nSTATUS, the behavior is as per your answer, a low pulse which is the image of nCONFIG slightly delayed so it goes high during the whole configuration process.

Sorry, by FPGA I mean the Flex, which I mistakenly called FPGA. But the Flex is not a true FPGA despite it has most of its characteristics.

1) Yes I use the .rbf file to configure the Flex.

2) What do you mean by "hardware setting has been checked"? Unless I missed something, the Flex is set up to be configured in passive serial (MSEL0&1 to GND, nCE to GND) 

3) Not tested the SOF file as the content is quite different from that of .rbf file. As per my understanding the SOF file needs some conversion from an intelligent programmer, this is why my preference goes for .rbf, as it might be the exact binary image to send to the Flex.

[Pierre95]

Sorry about question 1) yes there is 1K pullup to VCC on nSTATUS and CONF_DONE.

[WZ2]

Hi there,

Last time, I thought the "fpga" means your master device~

Anyway, I see the scenes is that you try to use AS configuration for "FPGA"'s config. And the signal's state show that the FPGA enter in config mode, however the configuration is failed and it cannot enter in user mode.

In my opinion, the greatest probability of this error is caused by the config file. Please make sure again the configuration file is right, like the setting of the flash or the little endian. In the other hands, do you have the configuration file which was succeed before and test the device has no problem~

Have a nice day~

Best regards,

[Pierre95]

Hello,

No I use PS (not AS) to configure the Flex , as the Flex gets configured from a microcontroller which drives the nCONFIG low and high after 5µs to trigger the configuration process.

DCLK and DATA0 are fed from the MCU. Now I am able to see CONF_DONE go high for 4µs (after all config file has been sent), then low again which migh signify an error in the configuration data?

I am not familiar with the behavior of CONF_DONE. Is there a test performed while it is already high which if wrong makes it go low again?

I can try to swap bytes to see if endianess could have some impact.

Wish you a nice day too,

Best regards

[WZ2]

Hi there,

Sorry for the delay~

The behavior of config_done is right, when it go high means that the device is in the stage of configuration and init was finished then it will go into user mode, when it go into user mode, config_donw become low again. Could u see the behavior of ini_done? If it go high and go low too, it means the init also successed~

[WZ2]

Hi there,

Is there any update?

[Pierre95]

Hi,

Finally, I got rid of this issue.

Firstly, there was some misprogrammed data in the Flash of the host microcontroller which resulted in sending erroneous config data to the Flex making nSTATUS go low in the "middle" of the configuration process.

After fixing this first issue, there was some concern about CONF_DONE going high for a few microseconds then Low again. 

What I've implemented to solve this issue:

-Send only the 28939 first bytes of the 28941 bytes from rbf config file.

-Send exactly 7 extra clock cycles with DATA0 high

-Poll for CONF_DONE high

-Send 10 extra clock cycles to initialize the device and start user mode.

If more than 7 extra clock cycle are sent before seeing CONF_DONE high, the config fails which is not documented in "nanopdf.com_configuring-flex-10k-devices-introduction.pdf". 

There are additional information in "an116.pdf" which say "if microprocessor sends all data and initialization clock starts but CONF_DONE &INIT_DONE have not gone high, it must reconfigure the target device."

At least it informs the initialization clock must not start before CONF_DONE &INIT_DONE have gone high which sounds contradictory about INIT_DONE intended to go high only after initialization is finished.

Moreover, no document states about not sending the last 2 bytes of the .rbf file, which makes it difficult to properly implement initialization algorithm from the official documents without experimenting.

Last point is CONF_DONE stays high once in user mode.

Thanks for the help you provided.

[WZ2]

Great job! Glad to see you solve it~