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

Tom Wallace tom.wallace at vesperix.com
Thu Oct 1 11:52:50 EDT 2015


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<mailto: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

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


More information about the USRP-users mailing list