05-25-2021 07:13 AM
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.
Solved! Go to Solution.
05-25-2021 08:17 AM
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.
05-25-2021 08:40 AM
Yep, installed. Tried installing again, just to be sure, but didn't help.
05-25-2021 11:46 AM
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.
05-25-2021 03:55 PM - edited 05-25-2021 04:01 PM
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.
07-14-2021 02:55 PM
@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.
07-14-2021 05:57 PM - edited 07-14-2021 06:20 PM
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.
07-15-2021 11:26 AM
@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!