Is your source block always trying to outputting packets? If so, your block could be trying to send packets while noc_shell is initializing. The easy fix is to add an enable register to hold off your block until after initialization.
On Wed, Jul 19, 2017 at 9:44 AM, Jason Matusiak via USRP-users < [email protected]> wrote: > Could this have something to do with tlast? I don't feel like it is the > XML files, so I am limited to looking at the verilog, but it is pretty > similar to my other blocks, so I am not sure what the problem could be. > > It is odd to me that the probing is enough to cause issues, I am not sure > what all gets executed in Verilog when the probe occurs. > > > > On 07/17/2017 03:36 PM, Jason Matusiak wrote: > >> I am not sure what is going on, but while working on my new RFNoC block, >> I can't probe my X310 anymore. When I do, I get this error: >> >> [INFO] [CORES] Performing timer loopback test... >> [ERROR] [UHD] Exception caught in safe-call. >> in virtual ctrl_iface_impl::~ctrl_iface_impl() >> at /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76 >> this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_00_Port_30) >> packet parse error - EnvironmentError: IOError: Expected SID: 02:30>00:00 >> Received SID: 02:60>00:00 >> terminate called after throwing an instance of 'uhd::io_error' >> what(): EnvironmentError: IOError: [0/Radio_0] sr_write() failed: >> EnvironmentError: IOError: Block ctrl (CE_01_Port_40) packet parse error - >> EnvironmentError: IOError: Expected packet index: 1003 Received index: 1002 >> Aborted (core dumped) >> >> >> Any idea where things are going off the rails? >> > > > _______________________________________________ > USRP-users mailing list > [email protected] > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
