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

Ian Buckley ianb at ionconcepts.com
Fri Oct 2 03:46:40 EDT 2015


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151002/2f0c24e2/attachment-0002.html>


More information about the USRP-users mailing list