[USRP-users] Software reset of B210

Dario Fertonani 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.

Dario










On Thu, Oct 1, 2015 at 6:51 AM, Marcus Müller <marcus.mueller at ettus.com>
wrote:

> 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,
> Marcus
>
>
> 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?
>
> Thanks,
> Dario
>
> 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.
>> /usr/local/lib/uhd/utils.
>> -D resets the device, -F only the FPGA, -U tries to reset the USB
>> subsystem on your computer.
>>
>> Best regards,
>> Marcus
>>
>>
>> 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"
>> interaction.
>>
>> Thanks,
>> Dario
>>
>>
>>
>> _______________________________________________
>> 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
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151001/b7fb5cec/attachment-0002.html>


More information about the USRP-users mailing list