LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA error: invalid or corrupt bitfile

I have just created a new version of one of my FPGA programs. The previous versions worked well and only a few changes were made to my new program.

 

When I compile this program it completes the compilation process without error. However, when it tries to start running the FPGA program I get the following error:

 

"The compiled bitfile for the specified VI contains information that is no longer valid or is corrupt. Recompile the VI to correct this error"

 

 

There is no error code for this message.

 

I have forced a recompile as well as deleted the first bitfile to ensure that a new one is created (unless the bitfile is saved in multiple locations?).

 

I am using LabVIEW 2010 and a PCIe-7842R FPGA.

 

Can anyone help me with this? I haven't found any similar postings, and without an error code it's hard to find helpful information.

 

Thanks!

0 Kudos
Message 1 of 23
(4,972 Views)

Can you verify that you're compiling for the correct target?

 

Did the previous version run on a different version of LV?  I don't have 2010, but maybe there were some small changes to how FPGA code is loaded.


--Using LV8.2, 8.6, 2009, 2012--
0 Kudos
Message 2 of 23
(4,962 Views)

The previous versions have all used LV 2010.

 

We only have one target loaded to the project, and to LV in general - the PCIe-7842R. I also just double-checked and it is still correctly linked within the project folder. The FPGA program is under, or is a subset of, the FPGA target.Additionally, I have configured the Host's FPGA Reference to the new FPGA program and saved it.

 

0 Kudos
Message 3 of 23
(4,960 Views)

Hi Lasertrap,

 

In the changes that you made from the original program, did you create any typedef controls, groupings of controls, or controls with Chinese or Japanese characters in the name? There were limited cases of this happening before when some of the above were used. Basically the problem comes from not being able to correctly convert the code for building the bit file. What version of the NI-RIO driver are you using? Some of the above cases listed a fix when used with NI-RIO 3.3 or later.

 

Can you still compile from the original project? If so, can you make the same changes to that FPGA code and try to compile there? Something may have been corrupted while moving from one project to the other.

 

Regards,

Peter W.

0 Kudos
Message 4 of 23
(4,949 Views)

I'm having a similar problem. LV2010 NI-RIO3.6.

 

It seems to be occurring only on the top level vi. The sub vis run correctly.

 

I have tried all the suggestions made so far and have recomplied everything. No special language charcters  in any files I am aware of.

 

has there been any further development on this issue?

 

henry

0 Kudos
Message 5 of 23
(4,892 Views)

Hi Henry,


I'm wondering if the same problem would appear if you create a new project and compile your FPGA code within that.  How difficult would it be for you to start a new project from scratch and add your targets and VIs into it, and then attempt compilation again?  What kind of FPGA target are you using in this scenario?  I'm interested to hear if this step make any difference for you.

0 Kudos
Message 6 of 23
(4,883 Views)

Thank you I had the same thought in the back of my head. I will try this.

I have a little more information to add to this.

 

The FPGA vi (top level) that causes this error only does so when interactive execution is requested. ie I try to run the top level vi from the desktop.

It is currently set to autoexecute and when called from the application appears to execute correctly.

 

Now on to the create new project and move everything idea.

I have always wondered why it is neccesary to drag some items from another project while others can be opened in the usual manner. Can you provide some technical background into what is happening that makes this neccesary?

 

Thanks again for your quick response.

 

henry

0 Kudos
Message 7 of 23
(4,880 Views)

Ok I have tried the new project/recompile without success.

I am working with a cRIO 9012 on a 9116 backplane

I have four modules in the project, but only 3 in the FPGA.( the fourth module will be added as soon as I have these three under control)

The three c series modules in the FPGA are all generic (custom )

 

The drivers for these three modules are the subvi in the top level and idividually they execute on the desktop fine.

 

The reason I am being a bit careful here is that I have had a deployment fail. I need to be certain that the next deployment will work and I don't have access to the deployed unit. It appears that this error may only be a problem at the desktop level. If so I can work around it.

 

h

0 Kudos
Message 8 of 23
(4,879 Views)

Hi Henry,


You should be able to add any files to your project by right clicking on the target and then clicking Add >> File.  Dragging files from one to the other should work in most scenarios as well, but you should be able to consistently add files to your project using the "Add" menu.

 

I'm interested in the fact that this executes on the desktop just fine.  Are you saying that when you click the "run" button, the FPGA code works as expected?  Is this using the FPGA in simulated I/O mode, or is it using actual I/O running on the actual FPGA target?

0 Kudos
Message 9 of 23
(4,872 Views)

Thanks Kyle.

 

Just to be as clear as I am able.

 

  • The subvi (CSeries module drivers) execute from the desktop fine I have modules in slot 3 5 and 7 and all three drivers for these modules run as expected when executed from the desktop.
  • Th top level FPGA comiles as expected and is configured to run when deployed.
  • The application can use the top level FPGA vi correctly and reliably perfrom the functions expected. (I have only tried this from the desktop and not through a deploy/autorun.I am also using a simple test application instead of the final app- the object is to verify the datapath from the modules.
  • When I try to run the FPGA top level vi from the desktop I get the bitfile corrupt error.
  • Both the origonal project and the new one have the same behaviour.

The question  is can I ignore this error or is something wrong here?

 

There is an apnote on your system that describes the process of changeing controllers.(http://zone.ni.com/devzone/cda/tut/p/id/5075)  I am wondering if this refers only to changeing controller types or does it include changing to another device of exactly the same configuration? It specifically requires that FPGA components are dragged from the referance project to the target. I have the same instructions from our thrid party card vendor and during the FPGA training I was told to do the same.

I would really like to understand what is happening in these cases. If you can shed more light on this unusual proceedure I would be most grateful.

Specifically why can these components not be added to a project the same manner normal vi are

and

If I have two controllers exactly the same can I merely change the IP of the controller point to it and deploy and run?  or do I need to create a new project, drag the FPGA stuff over  and insert the application recompile and deploy that way?

Im asking because I have been doing the former and If I am creating the origonal problem doing this  I need to change...

h

 

0 Kudos
Message 10 of 23
(4,868 Views)