usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

Re: Problem verifying B200 device

MD
Marcus D. Leech
Tue, Feb 21, 2023 6:24 PM

On 21/02/2023 12:59, Maxim Belotserkovsky wrote:

When I do dmesg following the initial 'cold connect' of B200, here is
what I see:

[ 7487.879251] vhci_hcd vhci_hcd.0: pdev(0) rhport(0) sockfd(3)
[ 7487.879260] vhci_hcd vhci_hcd.0: devid(393220) speed(3)
speed_str(high-speed)
[ 7487.879300] vhci_hcd vhci_hcd.0: Device attached
[ 7488.228451] usb 1-1: new high-speed USB device number 9 using vhci_hcd
[ 7488.378208] usb 1-1: SetAddress Request (9) to port 0
[ 7488.413199] usb 1-1: New USB device found, idVendor=2500,
idProduct=0021, bcdDevice= 1.00
[ 7488.413205] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 7488.413207] usb 1-1: Product: WestBridge
[ 7488.413208] usb 1-1: Manufacturer: Cypress
[ 7488.413210] usb 1-1: SerialNumber: 0000000004BE

Does this look correct? What bothers me here is the idProduct=0021,
which, according to
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
means a B210 device. Is this the kind of inconsistency that may be
causing the image load to fail?

I've tried running b2xx_fx3_utils, but any option I pass into it,
including the ones that are supposed jut query the device, try loading
up the image, so I can't get any more information about the state of
b200 on power-up beyond what's showing up in dmesg. What can possibly
be wrong with the USB configuration on my machine? Clearly, the
dropping of the device ONLY happens once I try running any of the UHD
utilities, but otherwise the connection seems rock-solid.

I did notice this: after initial cold connect, when I run 'usbipd wsl
list' from Windows Power Shell, I see "6-4  2500:0021  WestBridge" in
the list; however, same command issued after the botched image load
using any of the UHD utils shows this instead: "7-4    2500:0021
 Unknown", as if the firmware load causes the USB interface chip
(FX3?) to get bricked. I'm more inclined to think something is wrong
with the device or the firmware coming from Ettus than anything going
on with my host.

If you run:

sudo uhd_images_downloader

In your WSL instance, it will, if need be, download the appropriate
images into your filesystem environment, which will
  make them available for loading dynamically at UHD start-up.

I literally have nearly a dozen USRP B2xx type devices, and the only
time I've seen this type of issue is when
  the underlying host hardware isn't supporting it properly.  The
device WILL work with both USB2.0 and USB3.0
  host controllers, albeit with lower performance for USB2.0.  The
entire B2xx family is a fairly mature product,
  with very few changes to the host side or firmware/FPGA in quite some
time.   So I'm guessing that you're
  not running into "yeah, that version doesn't work" type issues.

I'm not a Windows/WSL user, so I'm not that familiar with how WSL/VM
handles USB.  My experience in the past
   with Windows VMs and USB is that they are not terribly reliable or
performant.  I have no idea whether this applies to
   WSL environments or not, and there may be others on the list who are.

How did you install UHD on your Ubuntu image?   The
packaged-by-canonical packages are entirely adequate--there's
  no need to build from source, if that's the route you took.

sudo apt install uhd uhd-host

Was just fine for me on my Ubuntu 22.04 system (on a probably 5 year old
laptop).

On Tue, Feb 21, 2023 at 11:31 AM Marcus D. Leech
patchvonbraun@gmail.com wrote:

 On 21/02/2023 12:24, Maxim Belotserkovsky wrote:
 Thank you for your answer. I have Ubuntu 22.04 running under WSL.

 To your points:
 1) I have considered power consumption issue, so I've tried
 plugging in the b200 via a powered hub - same problem. Try a
 different hub?
 2)ANY canned utility I've tried running (uhd_usrp_probe,
 uhd_find_devices) starts off by 'Loading firmware image:'. Just
 prior to running either command, the 'lsusb' in Ubuntu lists the
 device correctly (as 'Ettus Research LLC USRP B200-mini'), so
 presumably it is loaded with the factory image on power-up, or
 this is a wrong presumption on my part?
 3) USB interface is provided by a separate chip inside b200 (not
 the FPGA firmware), right? Why is it then that when image is
 being loaded the USB connection gets dropped? Is unsustainable
 power draw the only possibility?
 3) How do UHD utilities (say uhd_find_devices) "know" that the
 device has not image on it? Say, I use Xilinx program manager to
 load up the provided firmware image, and then try calling up one
 of the canned UHD utilities, are you saying the utility will then
 no longer attempt to load up anything because it can read some
 register on FPGA that will tell it it already has an image loaded?

 Perhaps there is a more detailed WIKI that explains these points
 in more detail? All I see online is fairly high level, hence my
 naive questions.
 Thanks!
 The UHD library queries the device to determine whether correct
 "stuff" has been loaded.     The firmware is for the
   FX3, and the FPGA image is for the FPGA.   They both need to be
 mutually compatible, and if UHD detects that there's
   either no images present, or that there's something "screwy" it
 will force reload of both the firmware (small) and
   the FPGA (much larger).  But once they're loaded, UHD startup
 will just proceed without reloading.   You're seeing
   multiple attempts to reload, because those attempts are failing,
 because there's something wrong with your
   USB host configuration.

 If you're running this under WSL, there may be some USB
 configuration issues that are causing your host controller
   to drop the device.

 In terms of "which registers do what", you'll need to look at the
 source code and FPGA code -- both of which are
   freely available.    There is no structured-walkthrough document
 available for FPGA programming on the B2xx
   series.  The RFNoC framework is not available for those devices,
 so any FPGA programming is done
   "bare metal".
 On Tue, Feb 21, 2023 at 11:06 AM Marcus D. Leech
 <patchvonbraun@gmail.com> wrote:

     On 21/02/2023 11:53, Maxim Belotserkovsky wrote:

Hi everyone. Got a brand-new B200-mini device, installed

     all the tools

etc. Ubuntu sees the device correctly once it's attached to

     the host:

<home>:~$ lsusb
Bus 001 Device 004: ID 2500:0021 Ettus Research LLC USRP

     B200-mini

...........

However, any attempt to run initial UHD verification (as per

     https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio),

for example, by running uhd_find_devices, fails in the

     following way :

<home>:~$ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400;
UHD_4.4.0.0-0ubuntu1~jammy1
[INFO] [B200] Loading firmware image:
/usr/share/uhd/images/usrp_b200_fw.hex...
No UHD Devices Found

When I re-run 'lsusb' now, The 'B200' device no longer

     shows up:

<home>:~$ lsusb
 ..................

At this point, it now requires power-cycling the B200 in

     order for it

to be recognized by the OS again (which presumably re-loads

     the

default factory image that comes on the built-in flash)

So, the problem is this: it appears as if in the process of

     loading

the firmware image (which comes as a part of running any of

     the UHD

utilities) the device loses connection to the system,

     causing it to no

longer enumerate on the OS, so that the subsequent steps (of
'uhd_find_devices' in our example) can no longer be

     executed (due to

'No UHD Devices found').

The questions I have are these :

  1. Is this something generally known, with a known
     solution, or is

there something wrong with my particular system, the B200

     device,

driver installation etc.?
2) Is the problem really caused by the FPGA image loading,

     or some

other non-FPGA component being disturbed causing the device to
disconnect? Is it possible the image attempted to be loaded

     the wrong

one( usrp_b200_fw.hex incompatible with the hardware)?
2) Is there a work-around? For example (preferred by me):

     can I run

UHD with the option passed to commands of not-loading the

     FPGA image

every time a command is executed? Say, a config file that

     UHD reads to

know what to do with the device? I want to be able to deal

     with the

B200 with whatever static image I've loaded up on it (be it

     the

factory image or some future custom image)

Thank you.


USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to

     usrp-users-leave@lists.ettus.com
     What version of Ubuntu?  What type of hardware?

     This might be that the USB controller on your host is dropped
     the device
     off the bus due to power-consumption.

     The FPGA/Firmware are only loaded during *cold start* of the
     device--that is after a power cycle.   Once it is loaded, as long
        as it's plugged in, and you don't ask for a different FPGA
     image, it
     will continue to run with that image.

     _______________________________________________
     USRP-users mailing list -- usrp-users@lists.ettus.com
     To unsubscribe send an email to usrp-users-leave@lists.ettus.com



 -- 
 Maxim Belotserkovsky​​​​

 maxim@gotenna.com

 <https://gotenna.com/>

--
Maxim Belotserkovsky​​​​

maxim@gotenna.com

https://gotenna.com/

On 21/02/2023 12:59, Maxim Belotserkovsky wrote: > When I do dmesg following the initial 'cold connect' of B200, here is > what I see: > > [ 7487.879251] vhci_hcd vhci_hcd.0: pdev(0) rhport(0) sockfd(3) > [ 7487.879260] vhci_hcd vhci_hcd.0: devid(393220) speed(3) > speed_str(high-speed) > [ 7487.879300] vhci_hcd vhci_hcd.0: Device attached > [ 7488.228451] usb 1-1: new high-speed USB device number 9 using vhci_hcd > [ 7488.378208] usb 1-1: SetAddress Request (9) to port 0 > [ 7488.413199] usb 1-1: New USB device found, idVendor=2500, > idProduct=0021, bcdDevice= 1.00 > [ 7488.413205] usb 1-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 7488.413207] usb 1-1: Product: WestBridge > [ 7488.413208] usb 1-1: Manufacturer: Cypress > [ 7488.413210] usb 1-1: SerialNumber: 0000000004BE > > Does this look correct? What bothers me here is the idProduct=0021, > which, according to > https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux > means a B210 device. Is this the kind of inconsistency that may be > causing the image load to fail? > > I've tried running b2xx_fx3_utils, but any option I pass into it, > including the ones that are supposed jut query the device, try loading > up the image, so I can't get any more information about the state of > b200 on power-up beyond what's showing up in dmesg. What can possibly > be wrong with the USB configuration on my machine? Clearly, the > dropping of the device ONLY happens once I try running any of the UHD > utilities, but otherwise the connection seems rock-solid. > > I did notice this: after initial cold connect, when I run 'usbipd wsl > list' from Windows Power Shell, I see "6-4  2500:0021  WestBridge" in > the list; however, same command issued after the botched image load > using any of the UHD utils shows this instead: "7-4    2500:0021 >  Unknown", as if the firmware load causes the USB interface chip > (FX3?) to get bricked. I'm more inclined to think something is wrong > with the device or the firmware coming from Ettus than anything going > on with my host. If you run: sudo uhd_images_downloader In your WSL instance, it will, if need be, download the appropriate images into your filesystem environment, which will   make them available for loading dynamically at UHD start-up. I literally have nearly a dozen USRP B2xx type devices, and the only time I've seen this type of issue is when   the underlying host hardware isn't supporting it properly.  The device WILL work with both USB2.0 and USB3.0   host controllers, albeit with lower performance for USB2.0.  The entire B2xx family is a fairly mature product,   with very few changes to the host side or firmware/FPGA in quite some time.   So I'm guessing that you're   not running into "yeah, that version doesn't work" type issues. I'm not a Windows/WSL user, so I'm not that familiar with how WSL/VM handles USB.  My experience in the past    with Windows VMs and USB is that they are not terribly reliable or performant.  I have no idea whether this applies to    WSL environments or not, and there may be others on the list who are. How did you install UHD on your Ubuntu image?   The packaged-by-canonical packages are entirely adequate--there's   no need to build from source, if that's the route you took. sudo apt install uhd uhd-host Was just fine for me on my Ubuntu 22.04 system (on a probably 5 year old laptop). > > On Tue, Feb 21, 2023 at 11:31 AM Marcus D. Leech > <patchvonbraun@gmail.com> wrote: > > On 21/02/2023 12:24, Maxim Belotserkovsky wrote: >> Thank you for your answer. I have Ubuntu 22.04 running under WSL. >> >> To your points: >> 1) I have considered power consumption issue, so I've tried >> plugging in the b200 via a powered hub - same problem. Try a >> different hub? >> 2)ANY canned utility I've tried running (uhd_usrp_probe, >> uhd_find_devices) starts off by 'Loading firmware image:'. Just >> prior to running either command, the 'lsusb' in Ubuntu lists the >> device correctly (as 'Ettus Research LLC USRP B200-mini'), so >> presumably it is loaded with the factory image on power-up, or >> this is a wrong presumption on my part? >> 3) USB interface is provided by a separate chip inside b200 (not >> the FPGA firmware), right? Why is it then that when image is >> being loaded the USB connection gets dropped? Is unsustainable >> power draw the only possibility? >> 3) How do UHD utilities (say uhd_find_devices) "know" that the >> device has not image on it? Say, I use Xilinx program manager to >> load up the provided firmware image, and then try calling up one >> of the canned UHD utilities, are you saying the utility will then >> no longer attempt to load up anything because it can read some >> register on FPGA that will tell it it already has an image loaded? >> >> Perhaps there is a more detailed WIKI that explains these points >> in more detail? All I see online is fairly high level, hence my >> naive questions. >> Thanks! > The UHD library queries the device to determine whether correct > "stuff" has been loaded.     The firmware is for the >   FX3, and the FPGA image is for the FPGA.   They both need to be > mutually compatible, and if UHD detects that there's >   either no images present, or that there's something "screwy" it > will force reload of both the firmware (small) and >   the FPGA (much larger).  But once they're loaded, UHD startup > will just proceed without reloading.   You're seeing >   multiple attempts to reload, because those attempts are failing, > because there's something wrong with your >   USB host configuration. > > If you're running this under WSL, there may be some USB > configuration issues that are causing your host controller >   to drop the device. > > In terms of "which registers do what", you'll need to look at the > source code and FPGA code -- both of which are >   freely available.    There is no structured-walkthrough document > available for FPGA programming on the B2xx >   series.  The RFNoC framework is not available for those devices, > so any FPGA programming is done >   "bare metal". > > >> >> On Tue, Feb 21, 2023 at 11:06 AM Marcus D. Leech >> <patchvonbraun@gmail.com> wrote: >> >> On 21/02/2023 11:53, Maxim Belotserkovsky wrote: >> > Hi everyone. Got a brand-new B200-mini device, installed >> all the tools >> > etc. Ubuntu sees the device correctly once it's attached to >> the host: >> > >> > <home>:~$ lsusb >> > Bus 001 Device 004: ID 2500:0021 Ettus Research LLC USRP >> B200-mini >> > ........... >> > >> > However, any attempt to run initial UHD verification (as per >> > >> https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio), >> >> > for example, by running uhd_find_devices, fails in the >> following way : >> > >> > <home>:~$ uhd_find_devices >> > [INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400; >> > UHD_4.4.0.0-0ubuntu1~jammy1 >> > [INFO] [B200] Loading firmware image: >> > /usr/share/uhd/images/usrp_b200_fw.hex... >> > No UHD Devices Found >> > -------------------------- >> > When I re-run 'lsusb' now, The 'B200' device no longer >> shows up: >> > >> > <home>:~$ lsusb >> >  .................. >> > ------------------------------------- >> > At this point, it now requires power-cycling the B200 in >> order for it >> > to be recognized by the OS again (which presumably re-loads >> the >> > default factory image that comes on the built-in flash) >> > >> > So, the problem is this: it appears as if in the process of >> loading >> > the firmware image (which comes as a part of running any of >> the UHD >> > utilities) the device loses connection to the system, >> causing it to no >> > longer enumerate on the OS, so that the subsequent steps (of >> > 'uhd_find_devices' in our example) can no longer be >> executed (due to >> > 'No UHD Devices found'). >> > >> > The questions I have are these : >> > 1) Is this something generally known, with a known >> solution, or is >> > there something wrong with my particular system, the B200 >> device, >> > driver installation etc.? >> > 2) Is the problem really caused by the FPGA image loading, >> or some >> > other non-FPGA component being disturbed causing the device to >> > disconnect? Is it possible the image attempted to be loaded >> the wrong >> > one( usrp_b200_fw.hex incompatible with the hardware)? >> > 2) Is there a work-around? For example (preferred by me): >> can I run >> > UHD with the option passed to commands of not-loading the >> FPGA image >> > every time a command is executed? Say, a config file that >> UHD reads to >> > know what to do with the device? I want to be able to deal >> with the >> > B200 with whatever static image I've loaded up on it (be it >> the >> > factory image or some future custom image) >> > >> > Thank you. >> > >> > >> > _______________________________________________ >> > USRP-users mailing list -- usrp-users@lists.ettus.com >> > To unsubscribe send an email to >> usrp-users-leave@lists.ettus.com >> What version of Ubuntu?  What type of hardware? >> >> This might be that the USB controller on your host is dropped >> the device >> off the bus due to power-consumption. >> >> The FPGA/Firmware are only loaded during *cold start* of the >> device--that is after a power cycle.   Once it is loaded, as long >>    as it's plugged in, and you don't ask for a different FPGA >> image, it >> will continue to run with that image. >> >> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >> >> >> >> -- >> Maxim Belotserkovsky​​​​ >> >> maxim@gotenna.com >> >> <https://gotenna.com/> >> > > > > -- > Maxim Belotserkovsky​​​​ > > maxim@gotenna.com > > <https://gotenna.com/> >