Jump to content
PJM_labview

Allocating Host (PC) Memory to do a DMA Transfer

Recommended Posts

Hi

We have an application where we need to have a custom PCIe board transfer data to the PC using DMA.

We are able to get this to work using NI-VISA Driver Wizard for PXI/PCI board.

The recommended approach is to have VISA allocate memory on the host (PC) and have the PCIe board write to it (as seen below).

9-30-2016 6-14-20 PM.png

While this approach works well, the memory allocated by VISA for this task is quite limited (~ around 1-2MB) and we would like to expand this to tens of MB.

Note: The documentation (and help available on the web) regarding these advanced VISA function (for instance "VISA Move out 32" and "VISA Move In 32") is parse. If someone has some deep knowledge regarding theses, please feel free to share how we could allocate more memory. 9-30-2016 6-36-01 PM.png

Since we are not able to allocate more memory using the VISA function at this time, we investigate doing the same operation using the LabVIEW Memory Manager Functions which allow us to allocate much larger memory block.

Below is the resulting code.

9-30-2016 6-20-29 PM.png

Unfortunately while we can validate that reading and writing to memory using this work well outside the context of DMA transfer, doing a DMA transfer do NOT work (although the board think it did and the computer is not crashing).

We are wondering why this is not working and would welcome any feedback.

Note: the DMA transfer implemented on the board requires contiguous memory for it to be successful. I believe that the LabVIEW Memory Manager Functions do allocate continuous memory, but correct me if I am wrong.

To troubleshoot this, I did allocate memory using the LabVIEW memory manager function and try to read it back using VISA and I got a "wrong offset" error (Note: This test may not be significant)

Another data point; while the documentation for DSNewPtr do not talk about DMA transfer, the one for DSNewAlignedHandle does. Experiment using LV memory manager Handles has not got us anywhere either.

We would welcome any feedback regarding either approach and about the LabVIEW Memory Manager Functions capabilities in that use case.

Thanks in advance.

PJM

Note: We are using LabVIEW 2014 if that matter at all.

 

Edited by PJM_labview

Share this post


Link to post
Share on other sites

Well, I'm pretty sure that for DMA transfer you do need a physical memory address.The LabVIEW DSNewPtr() function allocates a chunk on the process heap, which is a virtual memory area for each process. Between this virtual adress space and the actual physical address is the CPU MMU (memory management unit) which translates every address from the virtual memory to the actual physical memory address (and in the case of already cached memory locations actually, this step is skipped and directly translated to the cache memory location). The DMA controller only can transfer between physical memory addresses, which means for DMA transfer all the cache lines currently caching any memory that belongs to the DMA transfer block need to be invalidated.

So you first need to lock the virtual address block (the DMA controller would get pretty panicky if the virtual memory suddenly was moved/paged out) which will also invalidate the cache for any area in that block that is currently cached and retrieve its real physical address. Then you do the DMA transfer on the physical address and afterwards you unlock the memory area again, which also invalidates the physical address you previously got. Incidentially the services you need to access to do physical address translation and locking are all kernel space APIs. VISA comes with its own internal kernel driver, which exports functions for the VISA layer to do these things but performance suffers considerably if you do it this way. The alternative however is to have to write a kernel driver for your specific hardware. Only in the kernel driver do you have direct access to physical memory translation and such things, since these APIs are NOT accessible from the ring 3 user space, normal Windows processes are running in.

And yes, Windows limits the size of blocks you can lock. A locked memory area is a considerable weight on the leg of every OS, and in order to limit the possibility for a kernel driver to drown the OS for good, this limitation is necessary. Otherwise any misbehaving driver could simply DOS the OS by requesting an unreasonable big block to be locked.

Edited by rolfk

Share this post


Link to post
Share on other sites

Thank RolfK.

I was actually hoping that you would chime in on that topic :thumbup1:

We were suspecting something around the lines of what you described (Virtual memory address not appropriate for the DMA transfer). We will move forward and find out how to lock the memory.

Thanks again.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By RMowatt
      I am experiencing numerous VISA Lock Errors (-1073807345) on resources I haven't explicitly locked.  This is happening on TCPIP connections to keysight N6700 power supplies and keysight N5242 PNA fairly regularly.
      I have simultaneous loops in the application communicating to the different instruments, using a sequencer of sorts to pipe commands one at a time to each of my various loops.
      Has anyone seen the locking error pop before while not actually using the Lock and Unlock VIs?  This issue has gotten worse lately and it has come time to find the root cause.  My only thoughts are that it may have something to do with having NI MAX and Keysight Connection Expert both installed and possibly trying to "ping" these devices.  Every once in a while me sending commands and these "pings" may clash and cause the locking error.
      Error reads as follows:
      "Specified type of lock cannot be obtained, or specified operation cannot be performed, because the resource is locked. VISA error code -1073807345 (0xBFFF000F)"
      We are using LabVIEW 2013
      Thanks in advance!
    • By Ram Prakash
      Can anyone please tell what a DVR [ Data value reference ] is ? I want to know at what situation it will be used and what are the advantages we get by using DVR. I am really confused in this topic . If someone has any code in which they have worked with DVRs. kindly share it to me.
       
      Thank you.
    • By Benoit
      Hey guys,
      Can you take a look at this?
      The only work around I found is to dynamically open the connection with an external VI to make it fail so the second time it works.
      If anyone has an instrument that communicate trough TCP-IP with VI, please try on your side with LabVIEW 2018 and visa 18.
      https://forums.ni.com/t5/LabVIEW/VISA-error-with-TCP-IP-BK-precision-2190E/m-p/3876316
      Thanks
    • By szewczak
      I wanted to cross post metux's discovery here asap, and have a separate discussion.
      Metux's original post:
      The recent Linux driver package introduces a CRITICAL security vulnerability:
       
      http://www.ni.com/download/ni-linux-device-drivers-2018/7664/en/
       
      It adds additional yum/zypper repos, but explicitly disabling package signing and using unencrypted HTTP transport. That way, it's pretty trivial to completely takeover the affected systems, by injecting malicious packages.
       
       
      DO NOT INSTALL THIS BROKEN SOFTWARE - IT IS DANGEROUS !
       
      CERT and BSI are already notified.
       
       
       
       
       
    • By Tim_S
      Thought I'd pass this along and see if anyone can reproduce with different versions of LabVIEW. Appreciate it if anyone has seen this and has a fix.
      I'm using shared variables to communicate between applications (1:N). I'd been seeing some memory creep that was inconsistent and somewhat bizarre. Eventually managed to track it down to that I'm programmatically opening a connection to a shared variable in one loop, then reading the value in a different loop (the different loops have to do with reconnecting on connection loss and startup). There is a functional global used to pass the variable to the second loop. The Read Variable primitive deallocates all but 4 bytes of memory for the previous loop handle and then allocates memory for a new handle on each iteration of the while loop, hence creating a leak. This behavior does not occur if there is only one loop where there is an open, while loop with a read, and a close.
      Main.vi demonstrates the issue. Main 2.vi is more like the NI example.
      I've got service request #7728859 with NI going, but I think I got the guy's first day.
      LabVIEW 2015 SP1 32-bit on Win7 64-bit. Shared Variables memory leak.zip
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.