Calling Silicon Labs DLL From LV2012 vs LV2017

[RVines]

Hi guys,

Does anyone have a clue as to why the DLL, described below, behaves differently when only the LV Dev version is changed? I can run in LV2012 just fine but LV 2017 SP1 f3 is no good. I'm in the middle of upgrading all development code to 2017 and am currently stuck on this issue. 

We use a Silicon Labs CP2130 DLL "SLAB_SUB_SPI.dll" file version 1.2.0.1 product version 6.7.5.(0) USB-to-SPI Bridge converter. It works great in LV 12.0.0 64bit but does not work LV 17.0.1f3 64bit. 

NI-VISA 17.0 and MAX 18.0.0f0 are installed on my PC. The DLL is located in a project. Running a simple open close test VI in LV 2012 works great. Running in LV 2017 under the same exact path throws error code 17 when passing a pointer handle to "CP213x_GetOpenedVidPid()" call library function node. The pics below show this. After running once in LV2017 the device port is corrupted and has to be relocated to a new port before it can be detected again. I'll be posting to Silicon Labs as well to see if they have any insight.

This thread seams to hint at a solution by updating the DLL to a different version but doesn't actually explain what is happening behind the scenes.

[JÞB]

First,  I ll just put it out there.  Is the driver using  Code Interface Nodes or Call Library Fn nodes?

The demotion of CINs is my initial thought.

Do you have other versions of LabVIEW available to isolate the earliest version that breaks the code?

Does error 17 occur every time or can it run fine once after a reboot? Try a request deallocation after the close operation. 

Do you have a link to the relevant SIlabs docs?

I'm simply "Spitballing" here.  Even my 8-ball can't see too clearly on this.  Amazing. 

Maybe those questions will spark some ideas in yourself or another developer around here

[RVines]

The driver uses Call Library Function nodes.

LV 16.0f2 works great.

I suspect a restart of the PC works. Will give it a try. I'll also check for a dealloc call.

[rolfk · Accepted solution]

One thing that strikes me immediately is the fact that you say you use the 64-bit version of LabVIEW.

And a quick check in the header files for the Silicon Labs driver DLL shows that the device handle is an opaque pointer value, which is for 64-bit environments a 64-bit value. This means that the variable can (and often does) hold a 64-bit value that will get truncated if you force it into a 32-bit variable.

So basically everywhere your Call Library Node tries to pass the device handle to the function you have to reconfigure that parameter to be a pointer sized integer instead of a 32-bit integer. And in the LabVIEW VIs you need to make the according control to be a 64-bit integer. LabVIEW then has enough space to store the entire 64 bits in the wire (and the Call Library Node will convert the 64-bit value properly to 32-bit when you ever should decide to use the 32-bit version of LabVIEW.

Why it works in previous versions of 64-bit LabVIEW is a bit of a riddle. It could just have been bad luck that it did, or maybe some flag in the LabVIEW executable did indicate to Windows that it prefers 32-bit addresses or it was just full moon or something. But the 32 bit device handle was in fact syntactically wrong when used in a 64-bit environment and something just somehow happened to not cause the Silicon Labs driver to allocate the internal data structures a handle is pointing at to be allocated above the 32-bit limit.

The driver you use was either developed to support LabVIEW versions prior to 2009 (which was the first to be available as 64-bit version and support a distinctive pointer sized integer in the Call Library Node) or the person developing it was not aware about the differences between 32-bit and 64-bit operation.

[RVines]

Hi rolfk,

That fixed it! Changing each call to U64 and updating each CLFN worked great. The pointer handle was "deciding for an unknown reason" to be 64 bit and was subsequently truncated to 32 bit. I think the "full moon" idea is right on track.

The driver DLL was created by Silicon Labs. The wrapper was created by me in LV2012 using the auto-importer.

Regards,

Rob

[rolfk]

Please note that you should only use U64 for the LabVIEW Controls on the front panels to pass these handles through. The Call Library Node configuration should EXPLICITLY be configured to pointer-sized unsigned integer or you will get VERY BAD behaviour if you or someone else ever decides to use this library in 32-bit LabVIEW with a 32-bit compiled DLL. 

[RVines]

Thanks rolfk! I've changed the CLFN param type from "U64" to "Unsigned Pointer-size Integer" just in case it gets ported. The code runs great.