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 <[email protected]> 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 -- [email protected]
    > To unsubscribe send an email to [email protected]
    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 -- [email protected]
    To unsubscribe send an email to [email protected]



--
Maxim Belotserkovsky​​​​

[email protected]

<https://gotenna.com/>

_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to