[USRP-users] B210 Second CODEC Loopback Fail - SOLUTION

Michael West michael.west at ettus.com
Mon Oct 19 14:41:24 EDT 2015


The CODEC loopback failure has been resolved.  The fix is available in the
latest maint branch and will be included in the UHD 3.9.2 release.  The
resolution was much simpler than originally thought.  We simply added a 1ms
sleep between putting the AD936x in loopback mode and beginning the test.

Regards,
Michael

On Fri, Oct 2, 2015 at 12:46 AM, Ian Buckley via USRP-users <
usrp-users at lists.ettus.com> wrote:

> FWIW
> I've now bug fixed this in my UHD fork in a way that eliminates the (Host
> dependent) race condition entirely.
>
> https://github.com/ion-concepts/uhd/blob/b200_fixed_loopback/host/lib/usrp/common/ad936x_manager.cpp
> -Ian
>
> diff --git a/host/lib/usrp/common/ad936x_manager.cpp
> b/host/lib/usrp/common/ad936x_manager.cpp
> index 8c88978..f05b548 100644
> --- a/host/lib/usrp/common/ad936x_manager.cpp
> +++ b/host/lib/usrp/common/ad936x_manager.cpp
> @@ -19,6 +19,8 @@
>  #include <uhd/utils/msg.hpp>
>  #include <boost/foreach.hpp>
>  #include <boost/functional/hash.hpp>
> +#include <boost/date_time/posix_time/posix_time.hpp>
> +#include <boost/thread/thread.hpp>
>
>  using namespace uhd;
>  using namespace uhd::usrp;
> @@ -80,6 +82,16 @@ class ad936x_manager_impl : public ad936x_manager
>          }
>      }
>
> +  //
> +  // loopback_self_test checks the integrity of the FPGA->AD936x->FPGA
> sample interface.
> +  // It is a reasonably effective test for AC timing since I/Q Ch0/Ch1
> alternate over the same wires,
> +  // note however that it uses whatever timing is configured at the time
> the test is called rather
> +  // than select worst case conditions to stress the interface.
> +  // A test value is written to the codec_idle register in the TX side of
> the radio and this value propogates to AD9361
> +  // which in turn is configured in a special loopback mode that sends
> received sample values straight back to the baseband
> +  // unmodified. The RX side of the radio allows both the received value
> (as well as the TX value) to be read by the host
> +  // via the readback interface.
> +  //
>      void loopback_self_test(
>              wb_iface::sptr iface,
>              wb_iface::wb_addr_type codec_idle_addr,
> @@ -94,15 +106,25 @@ class ad936x_manager_impl : public ad936x_manager
>              boost::hash_combine(hash, i);
>              const boost::uint32_t word32 = boost::uint32_t(hash) &
> 0xfff0fff0;
>              iface->poke32(codec_idle_addr, word32);
> -            // We do 2 peeks so we have enough idleness for loopback to
> propagate
> -            iface->peek64(codec_readback_addr);
> +           iface->peek64(codec_readback_addr);
>              const boost::uint64_t rb_word64 =
> iface->peek64(codec_readback_addr);
>              const boost::uint32_t rb_tx = boost::uint32_t(rb_word64 >>
> 32);
>              const boost::uint32_t rb_rx = boost::uint32_t(rb_word64 &
> 0xffffffff);
> -            bool test_fail = word32 != rb_tx or word32 != rb_rx;
> -            if (test_fail) {
> -                UHD_MSG(status) << "fail" << std::endl;
> -                throw uhd::runtime_error("CODEC loopback test failed.");
> +           bool test_fail = word32 != rb_tx or word32 != rb_rx;
> +           boost::posix_time::ptime start_time =
> boost::posix_time::microsec_clock::local_time();
> +           boost::posix_time::time_duration elapsed;
> +           while(test_fail == 1) {
> +
> boost::this_thread::sleep(boost::posix_time::microseconds(100));
> +             elapsed = boost::posix_time::microsec_clock::local_time() -
> start_time;
> +             if(elapsed.total_milliseconds() > (1000)) // 1 second
> timeout.
> +               {
> +                 UHD_MSG(status) << "fail" << std::endl;
> +                 throw uhd::runtime_error("CODEC loopback test failed.");
> +               }
> +             const boost::uint64_t rb_word64 =
> iface->peek64(codec_readback_addr);
> +             const boost::uint32_t rb_tx = boost::uint32_t(rb_word64 >>
> 32);
> +             const boost::uint32_t rb_rx = boost::uint32_t(rb_word64 &
> 0xffffffff);
> +             test_fail = word32 != rb_tx or word32 != rb_rx;
>              }
>          }
>          UHD_MSG(status) << "pass" << std::endl;
> @@ -112,6 +134,8 @@ class ad936x_manager_impl : public ad936x_manager
>      }
>
>
> +
> +
>
>
> On Oct 1, 2015, at 9:15 AM, Dario Fertonani via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
> It works here! Thank you.
> Haswell CPU and Broadwell CPU both seem to need just one additional call
> to peek64.
>
> On Thu, Oct 1, 2015 at 8:52 AM, Tom Wallace via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>> If anyone else is seeing the B210 second CODEC loopback test fail
>> intermittently with UHD 3.9.x, as I was, the following change kills the
>> problem for me:
>>
>>
>>
>> diff --git a/host/lib/usrp/common/ad936x_manager.cpp
>> b/host/lib/usrp/common/ad936x_manager.cpp
>>
>> index 8c88978..60a09d3 100644
>>
>> --- a/host/lib/usrp/common/ad936x_manager.cpp
>>
>> +++ b/host/lib/usrp/common/ad936x_manager.cpp
>>
>> @@ -94,7 +94,8 @@ class ad936x_manager_impl : public ad936x_manager
>>
>>              boost::hash_combine(hash, i);
>>
>>              const boost::uint32_t word32 = boost::uint32_t(hash) &
>> 0xfff0fff0;
>>
>>              iface->poke32(codec_idle_addr, word32);
>>
>> -            // We do 2 peeks so we have enough idleness for loopback to
>> propagate
>>
>> +            // We do 3 peeks so we have enough idleness for loopback to
>> propagate
>>
>> +            iface->peek64(codec_readback_addr);
>>
>>              iface->peek64(codec_readback_addr);
>>
>>              const boost::uint64_t rb_word64 =
>> iface->peek64(codec_readback_addr);
>>
>>              const boost::uint32_t rb_tx = boost::uint32_t(rb_word64 >>
>> 32);
>>
>>
>>
>> This is probably the wrong way to fix it, of course – it could just fail
>> again on a faster machine, unless there’s some definite relationship
>> between the time it takes a peek to complete and the amount of delay
>> required. I’ll leave the appropriate permanent fix to the Ettus guys.
>>
>>
>>
>> Thanks to Ian Buckley for help in tracking this down.
>>
>>
>>
>> ---
>>
>>   Tom Wallace (tom.wallace at vesperix.com)
>>
>>   Vesperix Corporation
>>
>>   803 West Broad Street, Suite 520
>>
>>   Falls Church, VA 22046
>>
>>   Phone 703-224-4422   Mobile 703-220-8711
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://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
>
>
>
> _______________________________________________
> 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/20151019/f96ea6b3/attachment-0002.html>


More information about the USRP-users mailing list