USRP Software Radio

cancel
Showing results for 
Search instead for 
Did you mean: 

First-chance exceptions in niusrp.dll

Solved!
Go to solution

Is this the proper forum for Visual C++ questions for accessing the API of niusrp.dll?  I hope so...

 

I'm beginning to write VC++ code to control the Ettus N210.  The first call that my application makes into the DLL is to API function niUSRP_OpenTxSession.  That call seems to succeed, returning a zero status (no error), and giving me a valid session handle (non-zero).  However, when I make the call inside the Visual Studio debugger, I see a rash of "first chance exceptions" that occur while that API call is executing.  I know that a first chance exception is generally benign if handled, but I'm concerned that I may have a configuration problem because I wouldn't expect exceptions to be a natural part of the program flow.

 

Here is a listing of the exceptions I get.  This is in a legacy VC++ 6.0 application, calling the niUSRP API functions by indirect means (LoadLibrary and GetProcAddress), not by direct linkage.  I'm not sure if that matters.

 

       First-chance exception in ... (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
       First-chance exception in ... (MSWSOCK.DLL): 0xC0000005: Access Violation.
       First-chance exception in ... (MSWSOCK.DLL): 0xC0000005: Access Violation.
       First-chance exception in ... (MSWSOCK.DLL): 0xC0000005: Access Violation.
       First-chance exception in ... (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
       (many more identical exceptions omitted...)
       First-chance exception in ... (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
       First-chance exception in ... (KERNEL32.DLL): 0xC000008F: Float Inexact Result.

 

Can these exceptions safely be ignored?  Are they indications of a problem?

 

Thanks,

Ed

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

Hello Ed,

 

The USRP driver only has support for a limited number of RF daughter boards. Can I ask which daughterboard you have in your N210? Additionally I would like to know if you are using version 1.1 or 1.0 of the USRP driver on your computer.

 

I do not beleive we have published any text-based examples for programming the USRP. Could you post your function calls to LoadLibrary, GetProcAddress and the call to nuUSRP_OpenTXSession? I have not done this in C, but it is possible that LabVIEW doesn't pass these exceptions through since they are not fatal. I will need to look into this further to give you a better answer

 

 

Anthony F.
Staff Software Engineer
National Instruments
0 Kudos
Message 2 of 8
(8,369 Views)

The daughter board installed now is an "SBX Board Rev 3".

I also have a "Basic RX" board and "DC-50 MHz Receiver" board, neither of which I've tried yet.

 

Following is the essence of the code I am using.  The call to fpOpenTxSession generates the exceptions visible in the debugger, but returns gracefully.

 

// based on niUSRP.h, this is the signature of niUSRP_OpenTxSession (and Rx too):

typedef niUSRP_Status (__stdcall *FPOpenSession)(
   niUSRP_String deviceNames,
   niUSRP_Bool reset,
   niUSRP_Session* sessionHandle);

FPOpenSession fpOpenTxSession = NULL;

 

// load the USRP DLL, and map the OpenTxSession function

const char *libname = "niusrp.dll";
HINSTANCE hLib = LoadLibrary( libname );

FPOpenSession fpOpenTxSession = (FPOpenSession) GetProcAddress( hLib, "niUSRP_OpenTxSession" );

 

// open a TX session

niUSRP_Session session;

int niStat = fpOpenTxSession( "192.168.10.2", true, &session );

 

 

0 Kudos
Message 3 of 8
(8,361 Views)

Sorry, I forgot to include the version info for the niusrp.dll file.

I hope this is what you need...

 

From the readme file:

 

NI-USRP Readme

Version 1.0

 

From right-click properties on niusrp.dll:

 

File version is 1.0.0.49153.

In the "Other version information" section:

  Comments: 2011/09/01 19:29:29, niusrp/win32U/i386/msvc90/release

  File Version: 1.0.0f1

 

 

0 Kudos
Message 4 of 8
(8,358 Views)
Solution
Accepted by topic author ejubenville

Hello Ed,

 

Just as a heads up, version 1.0 may not work with those daughterboards as it was only tested with the XCVR2450 and WBX.  The NI-USRP version 1.1 adds support for the daughterboards you have (SBX, BasicTX, BasicRX and others).

 

I believe the first-chance exception is probably nothing to worry about, given the definition of a first-chance exception and the fact that the function calls are returning niUSRP_Status_Success.

 

Also, you may not have noticed but, there is a .lib file that you can statically link to instead of using the LoadLibrary and GetProcAddress calls.  This .lib is located at \Program Files\National Instruments\NI-USRP\lib

 

I would also double check the header file after you update.

Anthony F.
Staff Software Engineer
National Instruments
0 Kudos
Message 5 of 8
(8,347 Views)

Ed,

 

NI-USRP 1.1 adds support for your daughterboards.

 

As a C++ customer you are also encouraged to use the UHD (USRP Hardware Driver) which provides a C++ API and supports all of the Ettus daughterboards.

 

http://code.ettus.com/redmine/ettus/projects/uhd/wiki

 

Install instructions: http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Windows

Examples: http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/show/host/examples

API Documentation: http://files.ettus.com/uhd_docs/doxygen/html/namespaces.html

Message 6 of 8
(8,342 Views)

Upgrading to v1.1 of NI-USRP got rid of all but two of the exceptions.  I can live with the exceptions that remain, knowing that they are benign.

 

I saw a couple of differences in the niusrp.h file after the update.  The ability to get a list of all devices that can be reached on the network is nice, so now I can provide a default device (i.e., first in the list), which having to know the IP address in advance.

 

I was aware of the ability to use niusrp.lib to statically bind to the DLL, but I chose not to us it so that I can avoid the requirement for that DLL to be present just to start my application.

 

I also saw the recommendation to use the UHD driver for C++ development, but I have not yet investigated that option.  It looks like a bigger learning curve than just getting the niusrp APIs to work directly. 

 

The APIs supported by niusrp.dll seem fairly straight-forward, and my interface requirements are simple.  I just want to configure the device for frequency, sample rate, etc., and let it stream to me.   I've seen the LabView documentation, but I'm not a LabView guy, so it hasn't been the easiest thing to wade through.  I would also benefit from an overview of how to set the device up, i.e., which sequence of operations is required to get Rx data streaming.  Can anyone point me to documentation for the "big picture"?

 

Thanks,

Ed J. 

0 Kudos
Message 7 of 8
(8,332 Views)

Update:

 

I was able to find the following LabView link that helped me to understand the "big picture" that I had asked about earlier.  I'm up and running now.  Thanks for the help.

 

http://zone.ni.com/reference/en-XX/help/373380A-01/usrphelp/programming_flow/reference/en-XX/help/37...

Message 8 of 8
(8,328 Views)