fpga must recompile

[Craig_]

Make sure to use dynamic mode in the FPGA open function.

Can you enable debugging in the RT application exe and connect to it with the development environment?


How many pieces of software do you have installed to the 9073? Since it has only 64 MB of ram you have to be careful about what you put on it. Are you monitoring the memory usage of the program when you run it?

If you make a new project and create simple RT and FPGA VIs from scratch (blink the RT LED and the FPGA LED for example) can you get that to execute as startup?

Does downloading the FPGA bitfile into flash memory using RIO device setup start the FPGA when the target reboots?

[Dragis]

If you point the FPGA Open node at the bitfile directly by path, does the issue go away?

[longbow]

Yes, the app runs fine from the development environment.

Memory usage is no issue - as I said, this app runs 100% fine on LV2012.

I've done all the steps in http://digital.ni.com/public.nsf/allkb/52E943F7D6E7C0578625720A001DDF6E

such as delays before opening the FPGA to allow the OS to completely load.

The FPGA code itself is only around 17% of the FPGA.

This is the only piece of software on the RT - no scan engine, web services or anything else.

If I make a new app with blinking LEDS it runs.

It appears to be only this code written in LV 2012 that won't run properly in 2013

[longbow]

Only when running through the dev environment - it doesn't run at startup.

Debugging with the console out via RS232 produces no errors.

Diagram disabling the FPGA open allows the run at startup, putting it back breaks it.

But running throught the dev environment specifying the bitfile always works.

[longbow]

I've even done a "Turn LED on", "Wait 10 seconds", "Open FPGA via bitfile".

Dev environment - fine.

Runtime - does not turn on led.

Diagram disable Open FPGA - LED turns on at startup.

[BBedoustani]

Hi,

I have the same problem.

Did you solve the problem?

Yours,

[longbow]

Yes - when I took all fpga vi's out of a library, the problem stopped. Seems FPGA and libraries don't go well.

Even a new project with a new FPGA and VI's in a library caused the problem. Removed the library, and it worked.

[BBedoustani]

Thanks a lot,

Now it works for me too.

[Chris_12345]

We are also seeing weird behavior associated with Error -61017. We have a cRIO-9025 controller with a 9118 backplane, using LabVIEW 2012. In the controller code, we open an FPGA reference by specifying the FPGA VI in the “Open FPGA VI Reference” function. Everything was working fine, and then we needed to edit the FPGA front panel (changing some U16 arrays to U32 arrays), and also changing the FPGA build settings (optimized to minimize FPGA space). After doing that and re-building the FPGA code, we then built the DIU code. The DIU build went smoothly, but when running the startup.rtexe we would now get Error -61017 upon opening the FPGA reference. We tried a variety of cRIO build settings but still kept getting Error -61017 when running the startup.rtexe. Running the code in development mode would *not* yield Error -61017. We stumbled across a fix: on the development machine in the project, open the FPGA code, run it by clicking on the white arrow (if hardware is not connected, just ignore the error popup), switch the FPGA VI specified in the “Open FPGA VI Reference” function to another FPGA VI, switch it back to the correct one, then perform the cRIO build. The cRIO build will then yield a startup.rtexe that runs without Error -61017. Truly bizarre. We also tried specifying the bitfile instead of the FPGA VI, and that works (does not yield Error -61017).

[Chris_12345]

We are also seeing weird behavior associated with Error -61017. We have a cRIO-9025 controller with a 9118 backplane, using LabVIEW 2012. In the controller code, we open an FPGA reference by specifying the FPGA VI in the “Open FPGA VI Reference” function. Everything was working fine, and then we needed to edit the FPGA front panel (changing some U16 arrays to U32 arrays), and also changing the FPGA build settings (optimized to minimize FPGA space). After doing that and re-building the FPGA code, we then built the DIU code. The DIU build went smoothly, but when running the startup.rtexe we would now get Error -61017 upon opening the FPGA reference. We tried a variety of cRIO build settings but still kept getting Error -61017 when running the startup.rtexe. Running the code in development mode would *not* yield Error -61017. We stumbled across a fix: on the development machine, open the FPGA code, run it by clicking on the white arrow (if hardware is not connected, just ignore the error popup), switch the FPGA VI specified in the “Open FPGA VI Reference” function to another FPGA VI, switch it back to the correct one, then perform the cRIO build. The cRIO build will then yield a startup.rtexe that runs without Error -61017. Truly bizarre. We also tried specifying the bitfile instead of the FPGA VI, and that works (does not yield Error -61017).