Forum Discussion

Matan_b's avatar
Matan_b
Icon for New Contributor rankNew Contributor
2 years ago

Error (209014): CONF_DONE pin failed to go high in device 1. during programming encrypted jic file

Hi.

I am using Cyclone V device, (with MT25QL256 Flash attached) and I'm trying to implement a secure design that includes encryption with non-volatile key, protection from tampering and protection of the device from programming.

According to what I understood, the method to implement such a secure design is to produce an encryption key file -.ekp - and an encrypted configuration file when I enable the "tamper-protection bit" according to the instructions in the document "AN-556".

At first I tried to perform encryption without enabling the "tamper-protection bit" and everything worked fine - after burning the .ekp file - I was able to burn an encrypted and unencrypted configuration file (.jic file)and when I burned a file with an incorrect key - the configuration did not load after powering up.

After that I tried to encrypt now with the "tamper-protection bit" enabled (on another "clean" component - and I enabled the bit according to the instructions in the document AN-556), but now after burning the .ekp file, I am unable to burn a configuration file containing the correct key and receive this ERROR near the end of the burn:

Error (209014): CONF_DONE pin failed to go high in device 1. Make sure all communication cables are securely connected, select a different device, check the power on the target system, or make sure all nCE pins are connected to GND. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.

A detail that may have meaning - after burning the .ekp file - I turned the device off and on - (as I usually do after loading a configuration...) and only then tried to burn a configuration - could this be the source of the problem? On the other hand, according to my understanding, it shouldn't be a problem to burn a configuration file as long as it contains the right key?

I would like to get help and understand what I did wrong.

Thank you!

Compilation

3 Replies

  • FakhrulA_altera's avatar
    FakhrulA_altera
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi Matan_b,


    Have you checked that it is being loaded with an encrypted configuration file? Tamper protection mode prevents the FPGA from being loaded with an unencrypted configuration file. When you enable this mode, the FPGA can only be loaded with a configuration that has been encrypted with your key. Unencrypted configurations and configurations encrypted with the wrong key result in a configuration failure.


    Also, before programming the non-volatile key into the devices, ensure that you can successfully configure the FPGA with an unencrypted configuration file.


    Regards,

    Fakhrul



  • FakhrulA_altera's avatar
    FakhrulA_altera
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Please be advised that due to the absence of a response from you regarding the previous notification we provided, we will be transitioning this thread to community support. If you have any new questions or concerns, we kindly suggest opening a new thread to receive assistance from Intel experts. However, if you do not have any further inquiries, the community users will be available to assist you on this thread. Thank you for your understanding.


  • Matan_b's avatar
    Matan_b
    Icon for New Contributor rankNew Contributor
    2 years ago

    hi.

    thanks.

    I mistakenly thought that I should first burn the key file and then the configuration file, now I realized that I should first burn the configuration and then the key, I tried again on other device and it worked.
    My motivation is to lock the JTAG in order to prevent tamperIng as a result of burning another configuration into the system. Is there a way - on cyclone V - to lock the JTAG in another way besides the tamper protection bit which allows software to be updated to the system afterwards without "destroying" the JTAG interface?