[USRP-users] Software reset of B210
dario.fertonani at gmail.com
Thu Oct 1 11:05:54 EDT 2015
USB info on my PC:
$ lspci -v | grep -i usb
00:14.0 USB controller: Intel Corporation Device 8cb1 (prog-if 30 [XHCI])
00:1a.0 USB controller: Intel Corporation Device 8cad (prog-if 20 [EHCI])
00:1d.0 USB controller: Intel Corporation Device 8ca6 (prog-if 20 [EHCI])
Same command run a few months ago on the same HW with older Ubuntu version
(fished out from my Feb 24 message to this list):
$ lspci -v | grep -i usb
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB xHCI (rev 05) (prog-if 30 [XHCI])
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #2 (rev 05) (prog-if 20 [EHCI])
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #1 (rev 05) (prog-if 20 [EHCI])
Basically it's Intel 8 Series, typical of a Haswell Desktop PC.
UHD is compiled from source (via build-gnuradio script), giving string
UHD_003.008.005-10-g3dbced2d in each output. I reverted back from 3.9 after
seeing that it wasn't stable for our usage. I plan to upgrade to 3.9.1 soon.
The problem is relatively new, but I'm not sure this is a fair statement
since we started only recently to run very long LTE tests on B210, which
are the ones that trigger the problem. The flow goes like this: long MIMO
full-duplex run, app dies because recv stops getting samples, debug shows
the USB error, reset the board, repeat.
>From my side the SW solution you provided is good enough. Unless you have
something I can test, I'll defer and look more into this problem if it
persists after upgrading UHD.
On Thu, Oct 1, 2015 at 6:51 AM, Marcus Müller <marcus.mueller at ettus.com>
> Hi Dario,
> admittedly, not right now; transfer status 1 is "LIBUSB_TRANSFER_ERROR",
> which basically tells me nothing :(.
> Is that a new problem or did it exist before? What USB chipset are you
> using ("lspci|grep -i usb")?
> It's a bit surprising to me that uhd_usrp_probe still works, though. I'd
> like to reproduce; what's your UHD version?
> Best regards,
> On 30.09.2015 19:55, Dario Fertonani wrote:
> Thank you Marcus. That did work.
> Any idea on what could be the cause of the error?
> On Wed, Sep 30, 2015 at 9:00 AM, Marcus Müller <usrp-users at lists.ettus.com
> > wrote:
>> Hi Dario,
>> have you tried
>> b2xx_fx3_utils -D
>> You can usually find that program in your uhd/utils folder, e.g.
>> -D resets the device, -F only the FPGA, -U tries to reset the USB
>> subsystem on your computer.
>> Best regards,
>> On 30.09.2015 17:55, Dario Fertonani via USRP-users wrote:
>> I'm looking for a software command that resets B210 boards to a usable
>> state. Currently my default solution consists of unplugging the USB cable
>> (which is also the only source of power, in this setup), waiting a couple
>> of seconds, and plugging it back. This "solution" is not ideal as it
>> requires humans around the board.
>> My definition of unusable state is: B210 returns this message
>> terminate called after throwing an instance of 'uhd::runtime_error'
>> what(): RuntimeError: usb rx6 transfer status: 1
>> Interestingly, the unusable state doesn't prevent uhd_usrp_probe from
>> working and dumping the expected strings.
>> Any software solution available? UHD API or shell commands are both fine,
>> since the event is rare enough that we can tolerate some level of "manual"
>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users