Hello Sam,
rolling back to libusb 1.0.21 does indeed make things work better, but
I must say far from perfect.
D:\Libs\bin>uhd_find_devices.exe
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.1; Boost_106900;
UHD_3.14.1.0-release
No UHD Devices Found
Without any device connected, I finally have "No UHD Devices Found" and
successful return code 0. But with USB USRP device connected, it just
hangs, doesn't matter if it have firmware loaded or not.
D:\Libs\bin>uhd_find_devices.exe
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.1; Boost_106900;
UHD_3.14.1.0-release
*HANGS*
But I can at least get output from uhd_usrp_probe:
D:\Libs\bin>uhd_usrp_probe.exe
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.1; Boost_106900;
UHD_3.14.1.0-release
[INFO] [B200] Loading firmware image: C:\UHD\usrp_b200_fw.hex...
[INFO] [B200] Detected Device: B200mini
[INFO] [B200] Loading FPGA image: C:\UHD\usrp_b200mini_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
*SHORTENED*
As you can see, radio is working properly, and can get all properties
and device tree. If I try my test program, which calls only
uhd::device::find(hint, uhd::device::ANY);, i still do get exceptions
even without any USB device, but at least it terminates with return code
0.
Exception thrown at 0x00007FFC1C4A9129 in UHDTest.exe: Microsoft C++
exception:
boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error>
> at memory location 0x00000048601FB530.
Exception thrown at 0x00007FFC1C4A9129 in UHDTest.exe: Microsoft C++
exception: uhd::os_error at memory location 0x000000485F7DEB30.
The thread 0xfc has exited with code 0 (0x0).
The thread 0x820 has exited with code 0 (0x0).
The thread 0x138c has exited with code 0 (0x0).
The thread 0xe9c has exited with code 0 (0x0).
The thread 0x217c has exited with code 0 (0x0).
The thread 0x430 has exited with code 0 (0x0).
The thread 0x438 has exited with code 0 (0x0).
The thread 0x16dc has exited with code 0 (0x0).
The thread 0x1638 has exited with code 0 (0x0).
The thread 0x1c94 has exited with code 0 (0x0).
The thread 0x1dac has exited with code 0 (0x0).
The thread 0x22b8 has exited with code 0 (0x0).
The thread 0x1830 has exited with code 0 (0x0).
The thread 0x1330 has exited with code 0 (0x0).
The thread 0x3f0 has exited with code 0 (0x0).
The thread 0xdcc has exited with code 0 (0x0).
The program '[4644] UHDTest.exe' has exited with code 0 (0x0).
But I think it is safe to say, that libusb 1.0.22 and newer is causing
*some* problems.
Best regards,
Jakub
Dne 2019-08-30 16:36, Sam Reiter napsal:
Hey Jakub,
Thanks for the additional details. I can confirm that I've seen some
suspicious behavior from with UHD 3.14.1.0 binary on my machine since
you sent this in. It seems like libusb 1.0.22 causes crashing behavior
with uhd_find_devices. I rolled this back to libusb 1.0.21 and things
seem to have improved, but I need to do some more testing. I'd like to
know if you have similar results.
I'm going to get a fresh Windows image up and running today and see if
I can't characterize this any better on my end. I may reach back out
to you offline if there are any setup details we need to work through.
Otherwise, I'll try to post an update / resolution here once I have
it.
Sam
On Fri, Aug 30, 2019 at 6:13 AM Jakub Rybka <ry...@mtit.org> wrote:
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 [1] 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
Links:
------
[1] http://files.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
