Sam,
I do have drivers installed on Windows 10 machine. I can manage the code
to run by modifying UHD driver (commenting out libusb_unref_device), and
my radio is then properly found. What is bugging me, that even original
Ettus compiled UHD installer from files.ettus.com fails. If there are no
UHD devices connected, uhd_find_devices.exe just shows "No UHD Devices
Found". Under Windows, there is no such message. The program just fails,
and does NOT write this message. I tested it on multiple computers
running Windows 10 LTSC and Windows 10 Professional 1903.
Best regards,
Jakub
Dne 2019-08-29 16:54, Sam Reiter napsal:
Jakub,
I'll look into this. The issues you're reporting with the binary are
probably what I'll want to try to reproduce first. Can you be more
specific as to the behavior of your system during the crash you're
reporting? Screenshots would be useful if there are dialogs present
during / after the crash.
Beyond that, it sounds like you've had this system up and running with
a B series in the past, right? This would imply that you've installed
the Windows USB driver successfully:
http://files.ettus.com/manual/page_transport.html#transport_usb_installwin
and that you can see the B series device in the Windows Device manager
when connected.
Sam
On Thu, Aug 29, 2019 at 3:11 AM Jakub Rybka via USRP-users
<usrp-users@lists.ettus.com> wrote:
Hello,
I have encountered a strange problem using UHD 3.13 and 3.14
releases
under Windows. I am using X310 USRPs for some time now, and didn't
have
any problem with them. My development environment is Windows 10,
VS2017,
boost 1.67 and UHD versions 3.13 and 3.14. When I tried to use my
software with B200mini USRP device, UHD completely crashed. I did
some
investigation, and found out, that even original Ettus Research
binary
distribution crashes on USB devices.
Even this tiny bit of code crashes when compiled and run under
Windows:
int UHD_SAFE_MAIN(int argc, char *argv[])
{
std::string hint = "";
uhd::device_addrs_t addrs;
addrs = uhd::device::find(hint, uhd::device::ANY);
}
If you want to verify this does not work with USB devices at all,
just
run uhd_find_devices from UHD 3.14.1.0 binary release on bus series
USRPs. I did use
http://files.ettus.com/binaries/uhd/uhd_003.014.001.000-release/Windows-10-x64/uhd_3.14.1.0-release_Winx64_VS2017.exe
I did trace the problem with uhd::device::find to destructor
~libusb_device_impl(void), which calls libusb_unref_device. This
should
be called after libusb_free_device_list in libusb_device_list_impl,
but
when tracing the code, strange jumps occurs, and I suspect devices
are
unreferenced in destructor before they can be freed (but not
unreferenced) in libusb_free_device_list. This works perfectly under
linux, but not in Windows. It can be some compiler optimization
problem.
This is not the only problem in UHD, just *any* attempts to use USB
devices fails. uhd::usrp::multi_usrp::make for example runs, but
throws
some 4 exceptions.
More strangely, I suspect there is more to Windows UHD trouble. If I
do
this: uhd::device_addr_t addr; code fails with exception, with no
USRP
devices connected. It is very similar to
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-July/057279.html
.
Does anyone have any clue how to resolve this issue ? I am using
linux
as primary development OS with UHD, and I am not as fluent with MSVC
compilers. I am using Windows just to compile Windows version of my
USRP
software.
Variants tested:
Visual Studio 2015 and Visual Studio 2017, in their latest patch
versions.
Boost 1.67, 1.68, 1.69 and 1.70
libusb 1.0.22 and 1.0.23rc3
debug and release, static and dynamic, and static and dynamic
runtime
versions of all three libraries.
None does work.
Best regards,
Jakub Rybka
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
