[USRP-users] Exception in uhd_usrp_make (b205mini)

Nate Young nate.young at wde-llc.com
Wed Jul 1 14:03:13 EDT 2020


Thank you for the suggestion, unfortunately, the stock image (from
/usr/local/share/uhd/images/usrp_b205mini_fpga.bin) had the same error
message.
I also ran uhd_images_downloader to make sure the images were up to date,
as well as verified the udev rules were correct.

I started probing the board, and found that the output of the U9 clock
buffer chip is not correct.  It is 40MHz, but has a slower speed (~1MHz)
on/off modulation to it.
It turns out the capacitor C90 is no longer on my board !  This capacitor
provides stability to the LDO in the CDC3RL02 clock buffer chip, and
according to TI, will cause modulation on the output waveform.

So this is likely the cause.  It looks to be an 0402 or 0201 part, so I
have ordered some of those in 2.2uF and will see if I am able to replace it.


On Tue, Jun 30, 2020 at 9:38 PM Marcus D Leech <patchvonbraun at gmail.com>
wrote:

> Load the standard image and see if that makes a difference.
>
>
>
> Sent from my iPhone
>
> On Jun 30, 2020, at 10:24 PM, Nate Young via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
> 
>
> Hi All.
>
> I have an Ettus b205 that is being used in a customized HDL design that
> has been working reliably for many months through the development and
> addition of many features.
>
>
> Recently, the design stopped working and is now providing the following
> error during uhd_usrp_make() call from the host:
>
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.15.0.0-124-geb448043
>
> [INFO] [B200] Detected Device: B205mini
>
> [INFO] [B200] Operating over USB 3.
>
> *[ERROR] [UHD] Exception caught in safe-call.*
>
> *  in virtual radio_ctrl_core_3000_impl::~radio_ctrl_core_3000_impl()*
>
>   at /home/xyz/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:63
>
> *this->peek32(0); _async_task.reset(); -> AssertionError: accum_timeout <
> _timeout*
>
>   in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>
>   at /home/xyz/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:220
>
> To my knowledge, nothing has changed (Linux drivers, application C code or
> FPGA/HDL).     Previous code revisions (that have been working for months)
> no longer work.
> I have debugged and am starting to wonder if my b205 is broken.
>
> My system setup is an ODROID XU4 running the UHD firmware, connected over
> USB3 to the b205.  I have replaced the ODROID XU4, as well as the cable,
> but still get the same error.
>
> Linux lsusb sees the b205 with what I believe are the correct vendor and
> product ID.
>
> >> Bus 004 Device 004: ID 2500:0022
>
> The ODROID appears to be able to talk to the b205, as uhd_find_devices
> finds the b205.
>
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.15.0.0-124-geb448043
>
> --------------------------------------------------
>
> -- UHD Device 0
>
> --------------------------------------------------
>
> Device Address:
>
>     serial: 319B8D5
>
>     name: B205i
>
>     product: B205mini
>
>     type: b200
>
> In addition, the FPGA .bin file is being loaded.  I can generate custom
> FPGA builds that toggle various LEDs.. proving that the FPGA and at least
> one of its clocks are working.
>
>
> So, in summary, I get a timeout from radio_ctrl_core_3000's read of
> peek32(0).
>
> The host computer (ODROID XU4) sees the b205 via lsusb.
>
> The host computer can find the b205 using uhd_find_devices.
>
> The FPGA bitstream is being downloaded.
>
> Replacing the ODROID and the cable did not help.
>
>
> That is a strange combination. It seems to indicate the b205 is broken,
> but still working enough to download the fpga? Seems odd to me.
>
> I am working to get a new b205 to use as a comparison, but that will take
> a week or so.
>
> In the meantime, does anyone have suggestions on other ideas to try, or
> HDL changes (using Chipscope) that I might try to monitor to see if
> something is broken?
>
> Thank you very much.
>
> Nate
>
> _______________________________________________
> 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/20200701/81b219cd/attachment.html>


More information about the USRP-users mailing list