01-10-2014 09:15 AM - edited 01-10-2014 09:16 AM
We've had problems in our code where the FPGA is using a Wait on IRQ before it moves to another case and the main code starts running.
This is the only issue I have had with this code as the DMA FIFOs are working, FP communications are always working to control the FPGA and pass information to the RT code.
Occassionaly when I do a build of the RT EXE the Acknowledge Interrupts invoke node on the RT host has no effect on the FPGA Wait on Interrupt. The FPGA code is up and running on start-up, well before the RT OS launches the Start-up EXE - so it is not a matter of timing.
In the past I have corrected this by deleting the RT FPGA Interface Acknowledge Interrupts invoke node and replacing it and recompiling my code. This time around this invoke node replacement worked on one piece of hardware (sbRIO 9636) but not another. It would fail every time on the second piece of hardware. The image was being deployed from the 1st where the code would work using NI RIO Replication tools.
Is there a known issue with the Wait on Interrupts and Acknowledge IRQ on the sbRIO 9636?
Running LV 12.1 SP1 - locked in due to governing body constraints. I believe we are running RIO 12.1 (I am not at my office to check).
I have replaced the code with a loop that wait for a Boolean Start button value to be set True before the code moves on, as I have had no issue with FP communication to/from the FPGA and this is reliably working, I would just REALLY like to know why something so simple and that I have used on almost every cRIO project in the past is now intermittantly not working. It takes signifigant time to recompile to test these small "givens" and that really isn't good for project health!
We're only at 45% total Slice Usage.
01-13-2014 10:58 AM
Was the other piece of hardware that this was not working on an sbRIO9636 as well? This would be very odd behavior if so.
Are you getting any kind of error code when this happens?
Here is a note from the help document for the Wait on IRQ method:
"Note The Wait on IRQ method consumes threads. LabVIEW allocates a number of threads proportional to the number of processors on a machine. If the number of calls to the Wait on IRQ method equals or exceeds the number of available threads, other code in the application might stop executing until an interrupt occurs or the Wait on IRQ method otherwise returns. If you notice that other code in the application stops executing, try reducing the number of calls or put the Wait on IRQ methods in subVIs in different execution systems. Use the Execution Properties page to specify the execution system."
Do you think there are more threads being called than you can allocate? Just something I noticed that seemed like it could be correlated.
I haven't been able to locate anything else specific to this error from our internal resources. If you could post the code that is causing this error it might be beneficial.
01-13-2014 02:29 PM - edited 01-13-2014 02:33 PM
No - there is not an indication through the LabVIEW FPGA Interface Node on Acknowledge Interrupt that there was any issue with the Acknowledge IRQ node - there is no LabVIEW Error generated. The FPGA never sees the Interrupt as Acknowledged - which I verify through the "current state" FP indicator and the lack of the DMA FIFO filling (which it would do if the IRQ was acknolwedged).
No other code in the application appears to stop on the RT side (because nothing else is running in parallel at the time this call is made.). The FPGA code is designed to wait until the RT hits the acknowledge node.
We have one start-up VI that happens before all the other loops in the RT code start running - it calls subVIs of course - initializes buffers, opens connection to the FPGA (no error), sets up COM ports - inits Functional Globals, but everything is in series in this code as it is just start-up code. None of the parallel loops that WILL be running on the RT are allowed to proceed until this Init Code passes. All VIs before the Ack IRQ are finished executing, and nothing is running in parallel with the Ack IRQ - and there are no incoming errors into the node.
The other piece of hardware is also a sbRIO-9636 - the system is replicated to sbRIO-9636 - we are not attempting to use different hardware sbRIO families due to having to go through completely new approval processes.
01-14-2014 01:11 PM
I was able to find some information that states that the host RT VI cannot assert an interrupt on the FPGA line. The workaround for this is exactly what you are doing, using a boolean to synchronize a task. By doing this, you will actually get a faster rate between the host and the FPGA. Here are a couple KBs that have some benchmarks for more information:
Hope this helps!
01-14-2014 02:45 PM
I don't see where it says you can not use the FPGA Interface Palette and the Invode Node for Acknowledge Interrupt on the RT and the Wait on Interrupt on the FPGA - as the first link clearly states this is a typical use.
What I do see is that you can not write YOUR OWN interrupt routine. This HAS worked (albeit intermittently) in this project and in past projects on other cRIO systems.
Where did you find it stated that the RT can not assert an interrupt on the FPGA?
01-15-2014 05:49 PM
Are you able to confirm this behavior by using a simple project that will have no other variables, just the Wait on IRQ and Acknowledge Interrupt Invoke Node? I would like to confirm that this is not due to faulty hardware or something else in your program.
When you do this, can you post a quick picture of the code? If you are able to still get the error that way, it might be easier to attempt to reproduce.
I misspoke about the RT not being able to assert an interrupt on the FPGA. You cannot write your own interrupt service routine. If you have been successful in the past, it might be possible but it is not recommended.
01-24-2014 01:43 PM
I will try and replicate with a simple piece of code on one of our sbRIO-9636 boards when I have a break.