Hi Geoff, There has been a lot of investigation into a potential bug in the DmaFIFO RFNoC block logic, however it has been very difficult to consistently reproduce the issue. If you are able to provide code to reproduce the issue, that would be a huge help. If you have access to Vivado, you can also try applying the fix from this post and see if that helps: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-August/057721.html .
Jonathon On Tue, Jan 26, 2021 at 1:56 PM Geoffrey Mainland via USRP-users < usrp-users@lists.ettus.com> wrote: > I’m encountering a consistently reproducible problem on the X310 platform > that causes the radio to lock up to the point where I have to power cycle > it or flash it over JTAG to return it to a working state. > > My application is DragonRadio > <https://github.com/drexelwireless/dragonradio>, Drexel’s DARPA SC2 > competition radio. This radio can use either a TDMA MAC, which uses timed > TX bursts with a time spec, or an FDMA MAC, which uses TX bursts without a > time spec (has_time_spec is false). The problem occurs in both cases, so > it doesn’t seem to be related to the use of timed bursts. > > After several minutes of data transfer, one of the X310 radios will > produce the following error and lock up: > > EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no response packet - > AssertionError: bool(buff) > in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with > uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long unsigned > int] > at /root/dragonradio/dependencies/uhd/host/lib/rfnoc/ctrl_iface.cpp:151 > > At this point, I have to power cycle the radio or flash it over JTAG to > use it again. > > I am currently using UHD 3.15, but I have tried every UHD release since > 3.9 (except 3.12), and the same problem occurs. UHD 4 fails too, but the > error is slightly different: > > [ERROR] [X300] 192.168.40.2: x300 fw communication failure #1 > EnvironmentError: IOError: x300 fw peek32 - reply timed out > terminate called after throwing an instance of 'uhd::assertion_error' > what(): AssertionError: reply.sequence == request.sequence > in virtual uint32_t > x300_ctrl_iface_enet::__peek32(uhd::wb_iface::wb_addr_type) > at > /root/dragonradio/dependencies/uhd/host/lib/usrp/x300/x300_fw_ctrl.cpp:165 > > The problem *does not* occur with UHD 3.9. > > Both MACs only end a burst when they run out of data to send continuously, > and keeping them fed prevents the hang. > > My problem seems to be the same that is described in the closed GitHub UHD > issue > 203 <https://github.com/EttusResearch/uhd/issues/203>. As Brian Padalino > suggests in that issue, resizing the DRAM FIFO so latency is reasonable and > then zero stuffing the TX pipeline also prevents the radio from locking up. > I have not tried skip_dram=1. I also haven’t figured out how to resize > the DRAM FIFO with UHD 4, so I don’t know if the work-around applies to > that version. > > This problem is 100% reproducible with a few minutes (1–20) of run time. > Constructing a minimal failing example would be a lot of work, but the > radio I’m using is open source, so anyone should be able to reproduce the > problem (I’d be happy to provide additional instructions for doing so). > > Has anyone else seen this kind of behavior? There definitely seems to be a > bug in the DRAM FIFO. > > Thanks, > Geoff > _______________________________________________ > 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 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
