Error -52010 seen when using Wait on IRQ method

[nickstorton]

Hi All,

I am trying to synchronise the data connection between my FPGA vi and my Windows host vi and am using the Interrupt vi in my FPGA code and the wait on IRQ method in my windows host vi. When I run the code the windows host throws an error -52010 at the Wait on IRQ method saying "The requested resource must be initialized before use". I know that the FPGA vi is working because I can see all the data transactions on a logic analyser and the windows host worked before the addition of this method. Has anyone seen this behaviour before and figured out a fix?

Thanks in advance,

Nick

[Rob_Ward]

Dear Nick,

I have noticed you have an SR open with a colleague, Ben Marshall, who is looking into this also.  We are now working on this together to try to find the issue and a potential work-around.  It appears a Corrective Action Request (CAR) has been logged for this error message and behaviour so it is a know issue to NI.

Thank you for raising this issue with us.

Kind Regards,

[janwijman]

Today , I have also this problem with this error. I am very interested in the work-around of solution.

[nickstorton]

Hi Janwijman,

I probably need to further clarify the exact situation. My host architecture is based on a windows host vi that calls dynamic sub vis which communicate with the FPGA vi. The host vi opens a reference to the FPGA vi and uses the Run Method to start the FPGA code with no issues. Based on a user input by selecting one of the Test buttons on the host a sub vi is dynamically loaded and it’s front panel displayed. The FPGA reference is passed to this dynamic sub vi. It is this sub vi that then communicates with the FPGA vi and it is in here that the error occurs when the user selects the send command button. With this in mind the workaround is ...... The code in the Dynamic Sub vi will work correctly if you place the “Wait on IRQ” Method in the calling host vi. It doesn’t even need to be executed so you can put it in a case structure in say the false case, wire the reference and error straight through in the true case and wire a “True” boolean control to the case select terminal. You can see the effect of this further by placing a disable structure around the method inside the false case so it is now disabled, now the dynamic subvi will produce the error. Switch the diagram to enabled and the dynamic subvi will now work even though this portion of code is never executed because of the “True” control.

Hope this helps,

Nick

[janwijman]

Hi Nick,

Thanks for this reply. I will explain my sitiuation. I am working on a CRIO-9076. So it also happends in a RT-environement.  In the RT-software I use the vi's of the waveformreference of NI. The checking and acknowledging of the IRQ is done in the subvi: "rwfm_Start.vi". This  code is called via a method "StartAcquisition.vi" of a class "FPGA_CRIO.lvclass". I never had problems with this until yesterday. What I did as a work around on this problem looks in a way, I think, on your way. I filter the Error -52010. In attachement you will find a screen shot of the code. I see that this works. This error will not be visible, it is not important for may software. It the reset of the FPGA did not happen before this IRQ handling, other errors will appear.

[nickstorton]

Hi Janwijman,

I would say that you should be very careful with this workaround because the requested IRQ may not have been asserted yet by the FPGA section of the code but this error will still occur in the Wait method. Because you then filter the error and acknowledge the IRQ you may have a situation where you are acknowledging an IRQ that has not yet been asserted. Might I suggest that you place the Wait on IRQ method in your top level RT vi, place it in a case structure in the False case, wire a hidden boolean control to it that is True by default. This way the wait in the top level RT code will never run but you should not get the error in the sub vi and you can then wait for the IRQ to be asserted and acknowledge it correctly.

Hope this helps,

Nick

[janwijman]

Hi Nick,

Thanks. I did not think about this. I will check this

[GregFreeman]

I'm getting this error as well, but noticing it is only happening in the dev environment. I built and deployed and didn't have the problem. I have also noticed it is intermittent and yesterday when I fully cut power to the cRIO and rebooted it went away (even in the dev environment). I am using the latest NI Rio but am using LV 2011. Any status on the CAR? The work around listed above is not the best because my FPGA reference is in a class and that work around requires me to give access to the FPGA reference, thus defeating the whole point of encapsulation. That said, I haven't tried it yet just to see if it will resolve my issue. I'll try to get some time to do that in the near future.