Thanks for the updates. If you just want to reload the FPGA, try running "overlay rm n310 && overlay add n310" on the N310. This should simply reload the FPGA using the bistream already in the flash.
Wade On Fri, Dec 11, 2020 at 6:45 PM Rob Kossler <rkoss...@nd.edu> wrote: > Wade, > The following also fails using just 2 blocks and 2 attempts: > host_tx => Switchboard#0 => Switchboard#1 => host_rx // SUCCESS > host_tx => Switchboard#1 => Switchboard#0 => host_rx // FAILURE (RX > samples equal swapped I/Q of TX samples) > > In addition to wanting to get this issue fixed, I also have a question > about the best way to "reboot" the N310 which is what I need to do to fix > the issue after it occurs. One way is to give the "reboot now" linux > command. But, this takes a long time. Another way is to reprogram the > FPGA image via uhd_image_loader. This is appreciably faster, but I'm > thinking that this is not a great idea if the flash memory has a limited > number of write cycles before failure. Is there another way to achieve a > reboot other than these two? > Rob > > On Fri, Dec 11, 2020 at 7:34 PM Rob Kossler <rkoss...@nd.edu> wrote: > >> AHA! I duplicated the issue with the Switchboard image. The way to >> duplicate the issue is the run the following series of graphs: >> host_tx => Switchboard#0 => Switchboard#1 => host_rx // SUCCESS >> host_tx => Switchboard#2 => Switchboard#3 => host_rx // SUCCESS >> host_tx => Switchboard#0 => Switchboard#2 => host_rx // FAILURE (RX >> samples equal swapped I/Q of TX samples) >> Each of these 3 runs consists of running my application (similar to one >> of the examples such as rfnoc_rx_to_file) such that the UHD object is >> re-created each time. My guess is that you could use gnuradio to do it >> instead. >> >> My working theory is that the problem is caused by the fact that the >> Switchboard#2 input port was changed from being connected to the host in >> test case 2 to then be connected to another RFNoC block in test case 3. >> Or, I suppose it could be the output port on this block (same logic). >> >> If you want me to send you my FPGA image with the 4 Switchboard blocks, >> let me know. >> Rob >> >> >> >> On Fri, Dec 11, 2020 at 7:09 PM Rob Kossler <rkoss...@nd.edu> wrote: >> >>> Hi Wade, >>> After thinking about it a bit, I would ignore the "negation" issue for >>> now. This may be a byproduct of I/Q swapping related to my custom block. >>> Rob >>> >>> On Fri, Dec 11, 2020 at 6:34 PM Rob Kossler <rkoss...@nd.edu> wrote: >>> >>>> Hi Wade, >>>> Thanks for the info. I still do not know what's going on, but here are >>>> a few updates: >>>> >>>> - I built a new N310 image with 4 switchboards (1x1) and 1 >>>> splitstream (1x2) blocks in addition to the default blocks. All of the >>>> additional blocks are connected to SEPs for dynamic linking. I tried my >>>> best to get bad behavior using a chain of 1 to 4 switchboards, but I >>>> could >>>> not duplicate any I/Q swapping or negation issues. >>>> - I went back to my custom image (that I described below) and found >>>> different behavior today (sometimes things worked OK). So, this got me >>>> to >>>> thinking that I am somehow getting the FPGA in a bad state such that a >>>> reboot (or FPGA re-flashing) fixes things. I have had some success with >>>> re-booting and things working properly. But, I still do not have a true >>>> handle on things and cannot adequately predict when things are going to >>>> succeed or fail. >>>> - One thing that has been constant is that I have never seen bad >>>> behavior when I only have 1 block in my graph (no matter which block I >>>> choose). Note that for all of my tests, the graph looks like this: >>>> host_tx >>>> => block_chain => host_rx, where block_chain is a sequential chain of 1 >>>> or >>>> more rfnoc blocks. >>>> >>>> I will send a follow up once I figure things out. >>>> Rob >>>> >>>> >>>> On Fri, Dec 11, 2020 at 6:22 PM Wade Fife <wade.f...@ettus.com> wrote: >>>> >>>>> Hi Rob, >>>>> >>>>> The SEPs do have the ability to swap I and Q. This is because on the >>>>> host computer, I is usually in the lower bits and Q is in the upper bits >>>>> of >>>>> each 32-bit word, but in RFNoC, for historical reasons, I goes in the >>>>> upper >>>>> bits and Q in the lower bits. The software programs the IQ swapping when >>>>> it >>>>> sets up the graph. >>>>> >>>>> I assume you're using dynamic connections (through the crossbar) to >>>>> control the number of FFTs the data is passed through, and not static >>>>> connections? If that's the case then I wonder if software configures IQ >>>>> swapping incorrectly in some configurations. I'll see if I can do some >>>>> testing next week to confirm if it's working correctly. >>>>> >>>>> As for negation, I'm not aware of anywhere we do that off the top of >>>>> my head. Is that behavior block dependent? I'll see if I can find anywhere >>>>> this happens. >>>>> >>>>> Thanks, >>>>> >>>>> Wade >>>>> >>>>> On Thu, Dec 10, 2020 at 3:54 PM Rob Kossler via USRP-users < >>>>> usrp-users@lists.ettus.com> wrote: >>>>> >>>>>> Hi, >>>>>> I am encountering very strange behavior with a custom FPGA image >>>>>> (N310). It appears that data streaming through SEPs can get swapped (I/Q) >>>>>> and/or negated. Is anyone at Ettus aware of anything that could cause >>>>>> this? Of course, the issue might be on my end, but I can't think of what >>>>>> it might be given that all of my custom blocks work as expected in >>>>>> isolation (if the block is the only block in graph). >>>>>> >>>>>> My custom image is the following: >>>>>> >>>>>> - default blocks of Radios, DDCs, DUCs (each 2x2 and statically >>>>>> connected as in default image) >>>>>> - custom blocks of two 1x1 windowed-fft blocks, two 1x1 >>>>>> vector-avg blocks, and one 2x2 custom block. Note: each of these >>>>>> blocks is >>>>>> connected to its own SEP, so I can connect dynamically in any fashion. >>>>>> >>>>>> My test case is transmitting 8192 random samples from host to FFT >>>>>> block and then optionally through a 2nd FFT block before back to host. >>>>>> In >>>>>> the test case, the radios/DDCs/DUCs are not used. >>>>>> >>>>>> Here is what I observed: >>>>>> >>>>>> - If I only include 1 FFT block in my RFNoC graph, I get the >>>>>> expected results (the output from the FPGA matches what I calculate in >>>>>> Matlab for the FFT). This is true for either of the two FFT blocks. >>>>>> - If I include both FFT blocks in series, I can only match the >>>>>> FPGA output if I swap the I/Q values in between my Matlab FFTs. >>>>>> - Note: that this issue is not FFT-related as I can also >>>>>> duplicate this issue with the other blocks. >>>>>> - If I use 3 blocks in series (each through SEP), I need to >>>>>> negate certain data in order to get it to match the FPGA output >>>>>> >>>>>> My next step is likely to build a new image with Ettus-developed >>>>>> FIFOs to prove that the data is getting swapped/negated when 2 or more >>>>>> are >>>>>> used in series through SEPs. >>>>>> >>>>>> Let me know if you have any suggestions for other things to try. >>>>>> >>>>>> Rob >>>>>> _______________________________________________ >>>>>> 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
