Hey Nick,

No prob blew at all. The flag “no_reload_fpga” seems to work for that. The 
bigger problem is that each time the fpga image is loaded on the e3xx, the 
relative path delays between the RXA and RXB channels changes randomly as seen 
by the sample group jumps in the image I originally attached. The random LO 
phase is measured and removed, so there is something else happening in this 
strange case.

If anyone has any ideas as to what could be causing this please help! The phase 
stability of the E312 is amazing within the same fpga image cycle but these 
relatively large jumps after reload/ power cycle are a deal breaker for some 
applications!

Thanks

Sam

On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users 
<usrp-users@lists.ettus.com>, wrote:
> Sam,
>
> Sorry I haven't gotten back -- it sounds like you're doing everything right. 
> The usual quick fixes probably don't apply here. I haven't had time to look 
> more in depth into it, or to try to replicate it on my own hardware.
>
> Marcus is right -- the E3xx uses an idle image in order to reduce power 
> consumption when the radio is inactive. I'm not sure if there's a flag that 
> will tell UHD not to load the idle image.
>
> Nick
>
> > On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users 
> > <usrp-users@lists.ettus.com> wrote:
> > > On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
> > > > Still looking for more info on this problem.
> > > >
> > > > I have the exact same RfNoC block/software program running on an X300 
> > > > and see no such jumps or otherwise unexpected behavior.
> > > >
> > > > I have attempted to isolate this issue on the E312 by creating the 
> > > > device3 with the “no_reload_fpga” flag. (Appropriate image is loaded 
> > > > before hand with the uhd_usrp_image_loader. Running my program the 
> > > > first time works as expected, but if I kill the program and restart, I 
> > > > get this error:
> > > >
> > > > “AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in 
> > > > virtual void e300_fifo_mb::release()"
> > > >
> > > > The last few lines in the Uhd log file are:
> > > >
> > > >
> > > > e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to be 
> > > > stream 0
> > > >
> > > > device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for port 
> > > > #0 (SID; 00:00>02:10)
> > > > device3_impl.cpp:139,0,DEVICE3, OK
> > > > davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID 
> > > > 12AD100000000000.
> > > > e300_impl.cpp:639,1,E300, [E300] Setting up dest map for host ep 1 to 
> > > > be stream 1
> > > >
> > > > device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port for #1 (SID: 
> > > > 00:01>02:11)
> > > >
> > > >
> > > >
> > > > Shouldn’t the E312 be able to operate without needing to reload the 
> > > > FPGA image each time? Has this been tested? I would really appreciate 
> > > > any hints or pointers into why this is happening.
> > > >
> > > > Thank you,
> > > >
> > > > Sam
> > > >
> > > The E3xx run an "idle" image when the device is not being used.  I cannot 
> > > remember the reason for that, TBH.
> > >
> > >
> > > _______________________________________________
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to