LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2017 17.0.1f3 freezes when adding 'Call Library Function Node' with LibMPSSE

Solved!
Go to solution

I've been struggling with LabVIEW for the last few days. When trying to add in a 'Call Library Function Node' to my VI to call a function in LibMPSSE (https://ftdichip.com/software-examples/mpsse-projects/libmpsse-i2c-examples/#), LabVIEW crashes. When using a 32-bit library, the 32-bit version of LabVIEW crashes, and 64-bit library crashes 64-bit LabVIEW. LabVIEW 2018 with all service packs installed has also been tested with the same effect.


If I create the node with LabVIEW 64-bit, but link the 32-bit library, the program obviously won't run, but 32-bit LabVIEW also crashes when I try to open the file. This seems to only happen with LibMPSSE, though with all versions of it that I've tested.

The same issue occurs both on my laptop (Thinkpad T480) and desktop (Thinkstation P330) running Windows 10, 20H2.

 

All error logs are completely empty, and LabVIEW closes itself after not responding for a couple of minutes.

 

Has anyone experienced anything similar?

 

Attached minimal reproducible example.

0 Kudos
Message 1 of 8
(1,946 Views)

Did you install the D2XX driver from FTDI? This DLL depends on that driver and has a nasty bug in that it simply tries to load the D2XX driver and directly references it without checking if it was even possible to load it.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 8
(1,925 Views)

Yep, installed. Tried installing again, just to be sure, but didn't help.

0 Kudos
Message 3 of 8
(1,909 Views)

I'm not sure what they did with that DLL. It freezes on my computer too and not only when called from LabVIEW.

 

Looking at the source code for that DLL I do however have an idea what could be the problem. They do something that I have found recently to not work under Windows anymore reliably. A DLL is not supposed to try to load other DLLs explicitly in its DLLMain function. Until recently this did not seem to cause problems under Windows but somewhere last year Windows 10 acquired a problem with that and a process trying to load such a DLL often (but not always) will basically block in the Windows module loader lock until Windows decides that the process has died and forcefully terminates it.

 

Going to try to do some small modifications and see if it works. Will attach them to this post if they do work.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 8
(1,894 Views)
Solution
Accepted by ncom

Can you try the DLLs in this archive? I changed the source code from FTDI to initialize the library when the functions are for the first time called rather than when the DLL is loaded, so that the loader lock can be avoided. It loads on my computer without problems.

 

The only change I made to the API is that InitMPSSE() now returns an integer. If it is not 0, it could not find the FTDId2xx driver. But this function does not need to be called explicitly at all as it will be internally called when you call any of the I2C or SPI functions.

Rolf Kalbermatter
My Blog
Message 5 of 8
(1,884 Views)

@rolfk wrote:

Can you try the DLLs in this archive? I changed the source code from FTDI to initialize the library when the functions are for the first time called rather than when the DLL is loaded, so that the loader lock can be avoided. It loads on my computer without problems.

 

The only change I made to the API is that InitMPSSE() now returns an integer. If it is not 0, it could not find the FTDId2xx driver. But this function does not need to be called explicitly at all as it will be internally called when you call any of the I2C or SPI functions.


Hi @rolfk,

 

Thank you very much for finding a solution for this issue and sharing it with the community. I would like to get a few things clarified. 

 

  1. Regarding the InitMPSSE() function, are you referring to the FTDI_API void Init_libMPSSE(void); defined in the header file named 'libMPSSE_i2c.h' in your attachment? It doesn't seem to return an integer. Where did you actually change the API?
  2. I have a LabVIEW wrapper library for LibMPSSE that works well on LV 32 bit. But had issues loading on LV 64 bit even with the 64 bit version of LibMPSSE. But with your version (LibMPSSE fix) it just loads fine. Now I would like to modify my LabVIEW wrapper library such that it works for both LV 32 bit and 64 bit. I have identified (from one of your on post in another thread) that I needed to change int32 pointer to unsigned pointer sized integers in CLN and change front panel controls/indicators to uint64. Now the next thing is to wisely specify the dll name in CLN node in LabVIEW such that it could load the correct library for 32 and 64 bit. I know we can use the format with xx.x notation, but in the case of LibMPSSE both 32 bit and 64 bit dlls (in the fix files you shared) have the same name 'LibMPSSE.dll'. So how can I configure CLN to adapt to this? I am not sure if this works but will it be okay if I rename the 64 bit version of library 'LibMPSSE.dll' as 'LibMPSSE64.dll' and then use 'LibMPSSExx.x' in the call library function node?

    Thanks in advance

     
-----------------------------------------------------------------------------------------------------------------------------
Waiting For the inner calling 🙂


0 Kudos
Message 6 of 8
(1,738 Views)
Solution
Accepted by topic author rolfk

LibMPSSE.dll is supposed to be installed in the system directory. That will avoid all problems with trying to load the right DLL. The 64-bit DLL belongs into System32, the 32-bit DLL into SysWow64.

 

All FT_HANDLE parameters need to be configured as pointer sized integer in the Call Library Node in order for the VI library to work for both 32-bit and 64-bit DLLs.

 

The Init function is Init_LibMPSSE(). And yes the header for the i2c and spi both declare them still as having no return value. My modification is mainly in ftdi_infra.c, and there I modified it to return a status. And I added a call to this function in every low level API in ftdi_mid.c that accesses the ftdi DLL. As such you won't need to call Init_MPSSE() anymore yourself. It is however written in such a way that if the initialization has been successfully performed, calling it again is basically just a no operation and it returns immediately with success. 

 

I also reported this issue to FTDI and got a very quick response where they were confirming to have updated their beta repository with my suggestion. On reviewing I found that they had done kind of what I had suggested but not quite and I suggested to them again to improve the modification. They confirmed to have received that message and to go and look into it but I haven't heard anything from them since. The official release on their download site still seems to be the older 0.6 version. Their new Beta driver was supposed to have version 1.0.1.

Rolf Kalbermatter
My Blog
Message 7 of 8
(1,732 Views)

@rolfk wrote:

LibMPSSE.dll is supposed to be installed in the system directory. That will avoid all problems with trying to load the right DLL. The 64-bit DLL belongs into System32, the 32-bit DLL into SysWow64.

 

All FT_HANDLE parameters need to be configured as pointer sized integer in the Call Library Node in order for the VI library to work for both 32-bit and 64-bit DLLs.

 

The Init function is Init_LibMPSSE(). And yes the header for the i2c and spi both declare them still as having no return value. My modification is mainly in ftdi_infra.c, and there I modified it to return a status. And I added a call to this function in every low level API in ftdi_mid.c that accesses the ftdi DLL. As such you won't need to call Init_MPSSE() anymore yourself. It is however written in such a way that if the initialization has been successfully performed, calling it again is basically just a no operation and it returns immediately with success. 

 

I also reported this issue to FTDI and got a very quick response where they were confirming to have updated their beta repository with my suggestion. On reviewing I found that they had done kind of what I had suggested but not quite and I suggested to them again to improve the modification. They confirmed to have received that message and to go and look into it but I haven't heard anything from them since. The official release on their download site still seems to be the older 0.6 version. Their new Beta driver was supposed to have version 1.0.1.


 I have modified my LabVIEW libraries and it loads fine on both 32 and 64 it versions.

 

Thank you!

-----------------------------------------------------------------------------------------------------------------------------
Waiting For the inner calling 🙂


0 Kudos
Message 8 of 8
(1,705 Views)