LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DMA Read Problem

I am experiencing some extremely annoying behaviour with my FPGA / RT code.

 

I have a bitfile which works.  I can use it in a minimal test case where all DMA writes and Reads seem to work.  But when I incorporate it into a larger application, sometimes (for reasons unbeknownst to me) one of the Read channels stops working.  It's not that it blocks upon reading (with Timeout -1) but it returns immediately but the array output of the DMA Read node is empty.  There is NO ERROR.  This should essentially NEVER HAPPEN.  Telling a DMA Channel to give me 88 elements with a Timeout of -1 should either produce an error or wait until 88 elements are available.

 

It's almost as if the DMA Read node is being constant folded with an empty array (or the RIO driver is messed up)......  but only sometimes.  Of course the code is dependent on a rather large RT project and the bitfile won't even run without our specific hardware so submitting the code for purposes of reproducing the issue is very difficult.

 

We had a problem in the past where DMA Reads on an PXIe-8840 were showing similar behaviour (only ona  single-core kernel).  This was apparently fixed in the RIO driver.  Now I am seeing similar problems on a PXIe-8115.  Although it's weird that my minimal test case (using the SAME VIs) works but in the full software doesn't.  Again, it's only a read DMA which dowsn't work, the Write DMA works (being called int he same Timed loop as the Read).

 

Does this sound familiar to anyone?  It's driving me nuts.  I'm using LV 2015 SP1 15.0.1.f3.  NI RIO driverversion is 15.5.

0 Kudos
Message 1 of 2
(2,052 Views)

Aaaand of course as soon as I write that it works in my smaller program, it doesn't.

 

For the first time my stripped-down version showed the very same behaviour.  Simply shift-running the VI fixed the problem.  Then it also worked in my main VI.  Note that I have tried this combination dozens of times before to no avail.

 

It smells like there are some really funky things going on with compile cache / deploy.  Quite possibly having shared VIs used present in more than one target may significantly exacerbate the problem.

 

I remember making a comment about attaching a second mouse to a colleagues PC to really annoy them (by moving the second mouse out of their field of view to give them the impression their PC is haunted).  I am starting to get the impression that someone has reversed this joke on me.  My actions with RT / FPGA and the aforementioned problems do not feel like they are producing results in any kind of deterministic fashion.  Maybe the moon phase or the % humidity in the air is the key...

0 Kudos
Message 2 of 2
(2,044 Views)