Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: axi_wrapper with simple_mode=0... help me (Sylvain Munaut)
2. Re: No GPSDO found message (Michael West)
3. Re: No GPSDO found message (Roman Olesyuk)
4. custom RFNoC flowgraph seg faulting after update (Jason Matusiak)
5. Re: custom RFNoC flowgraph seg faulting after update
(Jason Matusiak)
6. Re: axi_wrapper with simple_mode=0... help me (Paolo Palana)
7. X310 : Error code -63150 (Sumit Kumar)
8. [IMAGE][FPGA] LUT's problem (Rub?n Vogel)
----------------------------------------------------------------------
Message: 1
Date: Thu, 9 Mar 2017 18:54:23 +0100
From: Sylvain Munaut <[email protected]>
To: Paolo Palana <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] axi_wrapper with simple_mode=0... help me
Message-ID:
<CAHL+j084NFCn_PmAftcvF8=y1jyqoevtk44haseooojpcfm...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> My problem is that, in this way, what I got is a TIMEOUT on the host. I
> have also setup the ILA and what I see is that after two packets the
> signal m_axis_data_tvalid
> coming from the axi_wrapper, to my logic goes down after two packet. I
> monitored also the s_axis_data_* from my logic to the the axi_wrapper
> and the waveform
> seems to be ok.
The CHDR header has things like the source and destination address for
the packet ... so you can't just pass it without changing it, you need
to actually fill-in the fields properly.
Look at what enabling simple_mode does inside the AXI wrapper and
that's about the minimum to do for it to work in simple cases.
Cheers,
Sylvain
------------------------------
Message: 2
Date: Thu, 9 Mar 2017 10:31:49 -0800
From: Michael West <[email protected]>
To: Roman Olesyuk <[email protected]>
Cc: Nikita Airee <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] No GPSDO found message
Message-ID:
<CAM4xKrpX-Us=S1NMqZbP=c+afss2uehtjz+4oab4d8ui6wd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Roman,
Thank you for the feedback. That all makes sense. I didn't realize the
fix went in after the tagged release. The fix is on the head of the maint
branch (3.10.x) as well as the head of the master branch (3.11.x). The
next 3.10.x will have the fix. Until then, please use the head of the
maint branch. My apologies for any inconvenience.
Regards,
Michael
On Wed, Mar 8, 2017 at 11:42 AM, Roman Olesyuk <[email protected]>
wrote:
> Hi Michael,
>
> Sorry for the late reply and thank you very much for your suggestion.
>
> Currently I am on UHD 3.10.1.1 from official Ubuntu PPA (with all GNU
> Radio and friends framework depending on 3.10 API). So first I have tried
> to build from sources 3.10.1.1 tag https://github.com/
> EttusResearch/uhd/tree/release_003_010_001_001 with different timeouts.
> So relative constant in this version is GPS_COMM_TIMEOUT_MS used at
> https://github.com/EttusResearch/uhd/blob/release_003_010_001_001/host/
> lib/usrp/gps_ctrl.cpp#L209 I changed it's value from 1300 to 10000. I
> also tried changing GPS_TIMEOUT_DELAY_MS and GPSDO_COMMAND_DELAY_MS from
> 200 ms to 1000 ms (just in case). It turns out that if
> GPS_COMM_TIMEOUT_MS value is increased GPSDO is detected as "generic NMEA
> GPS device", but it does not work:
>
> $ ./sync_to_gps
> ...
> -- Detecting internal GPSDO.... Found a generic NMEA GPS device
> ...
> UHD Warning:
> locked: ValueError: gps ctrl: No GPGGA message found
>
> UHD Warning:
> locked: ValueError: gps ctrl: No GPGGA message found
>
> UHD Warning:
> locked: ValueError: gps ctrl: No GPGGA message found
>
> Error: ValueError: locked(): unable to determine GPS lock statusThis could
> mean that you have
> not installed the GPSDO correctly.
>
> Then I have built UHD from the master branch (3.11). In this version in
> gps_ctrl.cpp at 210 line the timeout is hardcoded to 650 ms which is twice
> as less than GPS_COMM_TIMEOUT_MS = 1300 used in 3.10. But using the master
> branch GPSDO is detected and works just OK without any modifications. I
> have not done any code inspection of the differences between 3.10.1.1 and
> 3.11 master version. But it seems that the issue is fixed in the master
> branch. I would appreciate (and may be others too) if the fix is backported
> to the 3.10 branch as it is current stable release.
>
>
> 2017-03-01 22:24 GMT+03:00 Michael West <[email protected]>:
>
>> When using PCIe, the FPGA image is reloaded. That causes a reset of the
>> GPSDO. The changes in the commit attempted to wait long enough for the
>> GPSDO firmware to initialize, but not so long as to slow down device
>> initialization if no GPSDO was present. You can try increasing the timeout
>> on this line to see if it fixes the issue:
>> https://github.com/EttusResearch/uhd/blob/master/host/lib/
>> usrp/gps_ctrl.cpp#L210
>>
>> Regards,
>> Michael
>>
>> On Tue, Feb 28, 2017 at 1:57 AM, Roman Olesyuk <[email protected]>
>> wrote:
>>
>>> Hi Michael,
>>>
>>> I use the latest UHD and FPGA image 3.10.1.1 and still experiece this
>>> issue. My OS is Ubuntu 16.04.2, kernel 4.4.0-64-generic #85 x86_64, NI RIO
>>> drivers 15.0.0. In addition I have unstable PPS/GPS LOCK behavior as
>>> desribed in my previous email (e.g. stable PPS/GPS LOCK only when PC with
>>> PCIe card is power off).
>>>
>>> --
>>> ? ?????????, ????? ??????.
>>> Yours sincerely, Roman Olesyuk.
>>>
>>>
>>> 28 ????. 2017 ?. 10:33 ???????????? "Nikita Airee" <[email protected]>
>>> ???????:
>>>
>>> No Roman, I don't see such a behaviour in my USRP. Because in my case
>>> the GPS refuses to lock but the PPS works fine blinking every second. Did
>>> you try the patch? Does it work for you?
>>>
>>> Michael, thanks for your suggestion! But it seems like it is not working
>>> for me. It is entirely possible that I may be doing something wrong because
>>> I have never patched a commit before. But the gps_ctrl.cpp file does change
>>> at its location <working directory>/uhd/host/usrp/.
>>>
>>> Also for when the gpsdo does work, ie with Ethernet, how do I get this
>>> gpsdo to lock? I suppose simply running sync_to_gps should time and
>>> reference lock my gpsdo?
>>>
>>> Bests,
>>> Nikita
>>>
>>>
>>> On Tue, Feb 28, 2017 at 4:06 AM, Michael West <[email protected]>
>>> wrote:
>>>
>>>> Hi Nikita,
>>>>
>>>> Sadly, we know what this issue is. We sped up the X300 initialization
>>>> so much that the firmware on the GPSDO does not have time to finish
>>>> initializing before the detection code runs. The problem was fixed in the
>>>> 3.10.1.1 release, but for some reason the fix did not get applied to the
>>>> 3.9.6 release. The specific commit that is needed is
>>>> https://github.com/EttusResearch/uhd/commit/63fcfb9574d64797
>>>> b807a0dd356f5d7bfc48f082
>>>>
>>>> You can try to patch with that commit until we get it properly fixed.
>>>> We should have it fixed on the LTS branch soon.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Mon, Feb 27, 2017 at 12:27 PM, Roman Olesyuk via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Nikita,
>>>>>
>>>>> I experience the same issue. In addition I observe the following
>>>>> behavior. I checked LEDs on GPSDO board. Two green LEDs are on for
>>>>> several seconds when I power on X310 and then they go off. If the PCIe
>>>>> connector is plugged in, but PC is powered off, in about 30-60 seconds I
>>>>> observe that PPS LED starts blinking once per seconds, and after about 10
>>>>> minutes GPS LOCK LED (on GPSDO boards and on the front panel) goes on.
>>>>> This
>>>>> is very stable behavior when PCIe IS PLUGGED IN, BUT PC IS OFF. I can get
>>>>> very stable GPS lock (the LED is on as long as I can observe) and PPS is
>>>>> always blinking. If I use 1Gbps network connection (with PCIe connector
>>>>> unplugged) or if I use PCIe connection (just power on X310, then power on
>>>>> PC), I do not see PPS blinking even after several minutes. Sometimes PPS
>>>>> LED goes blinking and after 10-60 seconds it goes off again. Very rarely I
>>>>> can see PPS blinking for several minutes and GPS LOCK LED is even rarer
>>>>> (almost never see it). The behaviors are almost the same in PCIe and 1Gbps
>>>>> modes. So it looks for me like some FPGA/GPSDO initialization problem.
>>>>>
>>>>> Can you confirm my observations?
>>>>>
>>>>> --
>>>>> Yours sincerely, Roman Olesyuk.
>>>>>
>>>>> 2017-02-27 13:43 GMT+03:00 Nikita Airee via USRP-users <
>>>>> [email protected]>:
>>>>>
>>>>>> Hi list,
>>>>>>
>>>>>> the information I had provided might not have been enough. So here is
>>>>>> some more:
>>>>>>
>>>>>> My X310 has internal GPSDO. This is visible to UHD when I perform
>>>>>> uhd_usrp_probe provided it is connected to my laptop using Gigabit
>>>>>> ethernet:
>>>>>>
>>>>>> linux; GNU C++ version 4.8.4; Boost_106000;
>>>>>> UHD_003.009.006-0-g122d5f8e
>>>>>>
>>>>>> -- X300 initialization sequence...
>>>>>> -- Determining maximum frame size... 1472 bytes.
>>>>>> -- Setup basic communication...
>>>>>> -- Loading values from EEPROM...
>>>>>> -- Setup RF frontend clocking...
>>>>>> -- Radio 1x clock:200
>>>>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>>>>> Firmware Rev 0.929a*
>>>>>> -- Initialize Radio0 control...
>>>>>> -- Performing register loopback test... pass
>>>>>> -- Initialize Radio1 control...
>>>>>> -- Performing register loopback test... pass
>>>>>> ...
>>>>>>
>>>>>> However, when I use PCI Express for connection, it says:
>>>>>>
>>>>>> linux; GNU C++ version 4.8.4; Boost_106000;
>>>>>> UHD_003.009.006-0-g122d5f8e
>>>>>>
>>>>>> -- X300 initialization sequence...
>>>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>>>>> rp_x310_fpga_HGS.lvbitx...
>>>>>> -- Setup basic communication...
>>>>>> -- Loading values from EEPROM...
>>>>>> -- Setup RF frontend clocking...
>>>>>> -- Radio 1x clock:200
>>>>>> --
>>>>>>
>>>>>>
>>>>>> *Detecting internal GPSDO.... UHD Error: GPS invalid reply "",
>>>>>> assuming none availableNo GPSDO found*
>>>>>> -- Initialize Radio0 control...
>>>>>> -- Performing register loopback test... pass
>>>>>> -- Initialize Radio1 control...
>>>>>> -- Performing register loopback test... pass
>>>>>> ...
>>>>>>
>>>>>> When the same USRP is connected to a laptop with a different UHD
>>>>>> version via PCIe, I get:
>>>>>>
>>>>>> linux; GNU C++ version 4.8.2; Boost_106000;
>>>>>> UHD_3.11.0.git-28-gc66cb1ba
>>>>>>
>>>>>> -- X300 initialization sequence...
>>>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>>>>> rp_x310_fpga_HG.lvbitx...
>>>>>> -- Setup basic communication...
>>>>>> -- Loading values from EEPROM...
>>>>>> -- Setup RF frontend clocking...
>>>>>> -- Radio 1x clock:200
>>>>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>>>>> Firmware Rev 0.929a*
>>>>>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1186.1MB/s)
>>>>>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1189.4MB/s)
>>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>>> -- Performing timer loopback test... pass
>>>>>> -- Performing timer loopback test... pass
>>>>>> ...
>>>>>>
>>>>>> Also when I try sync_to_gps, it says:
>>>>>> ...
>>>>>> Waiting for reference lock...LOCKED
>>>>>> *WARNING: GPS not locked - time will not be accurate until locked *
>>>>>> USRP time: 1136078288.000000000
>>>>>> GPSDO time: 1136078288.000000000
>>>>>>
>>>>>> SUCCESS: USRP time synchronized to GPS time
>>>>>>
>>>>>> On querying gpsdo sensors soon after, I find that :
>>>>>>
>>>>>> USRP Locked to GPSDO 10 MHz Reference.
>>>>>>
>>>>>> GPS and UHD Device time are NOT aligned;
>>>>>> last_pps: 9 vs gps: 1136078227. Trying to set the device time to GPS
>>>>>> time...
>>>>>> -- 1) catch time transition at pps edge
>>>>>> -- 2) set times next pps (synchronously)
>>>>>> last_pps: 1136078231 vs gps: 1136078231.
>>>>>> GPS and UHD Device time are aligned.
>>>>>> Printing available NMEA strings:
>>>>>> GPS_GPGGA: $GPGGA,011711.00,0000.0000,N,0
>>>>>> 0000.0000,E,0,99,1.0,0.0,M,0.0,M,,*5B
>>>>>> GPS_GPRMC: $GPRMC,011711.00,V,0000.0000,N
>>>>>> ,00000.0000,E,0.0,0.0,010106,,*25
>>>>>> GPS Epoch time at last PPS: 1136078232.00000 seconds
>>>>>> UHD Device time last PPS: 1136078232.00000 seconds
>>>>>> UHD Device time right now: 1136078232.27291 seconds
>>>>>> PC Clock time: 1487756260 seconds
>>>>>> ...
>>>>>>
>>>>>> Could anybody please help me with this? I suppose that when the gps
>>>>>> is locked, it means that uhd is time aligned with gps? If so, I would
>>>>>> also
>>>>>> really like to know exactly how you permanently lock gps.
>>>>>>
>>>>>> Bests,
>>>>>> Nikita Airee
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 21, 2017 at 8:20 PM, Nikita Airee <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi list,
>>>>>>>
>>>>>>> I have:
>>>>>>>
>>>>>>> Ubuntu 14.04
>>>>>>>
>>>>>>> UHD: 003.009.006-0-g122d5f8e
>>>>>>>
>>>>>>> USRP X310 with CBX20 + GPSDO
>>>>>>>
>>>>>>> I moved to UHD 3.9.6 very recently and since then have been facing the
>>>>>>> following issue related to GPSDO:
>>>>>>>
>>>>>>> *UHD Error: GPS invalid reply "", assuming none available
>>>>>>> No GPSDO found*
>>>>>>>
>>>>>>> UHD_3.11.0.git-28-gc66cb1ba would never throw up this message.
>>>>>>>
>>>>>>> Is this a known issue? If not, how do I use GPSDO?
>>>>>>>
>>>>>>> Bests,
>>>>>>>
>>>>>>> Nikita Airee
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ? ?????????, ????? ??????.
>>>>> Yours sincerely, Roman Olesyuk.
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
> --
> ? ?????????, ????? ??????.
> Yours sincerely, Roman Olesyuk.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/2bb86aa1/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 9 Mar 2017 21:33:34 +0300
From: Roman Olesyuk <[email protected]>
To: Michael West <[email protected]>
Cc: Nikita Airee <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] No GPSDO found message
Message-ID:
<CAMZegnHaQzdrScVSboAWST=vaWBOmcb=pi5j_f0772zmeu+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Thank you very much for the help in resolving of the issue.
2017-03-09 21:31 GMT+03:00 Michael West <[email protected]>:
> Hi Roman,
>
> Thank you for the feedback. That all makes sense. I didn't realize the
> fix went in after the tagged release. The fix is on the head of the maint
> branch (3.10.x) as well as the head of the master branch (3.11.x). The
> next 3.10.x will have the fix. Until then, please use the head of the
> maint branch. My apologies for any inconvenience.
>
> Regards,
> Michael
>
> On Wed, Mar 8, 2017 at 11:42 AM, Roman Olesyuk <[email protected]>
> wrote:
>
>> Hi Michael,
>>
>> Sorry for the late reply and thank you very much for your suggestion.
>>
>> Currently I am on UHD 3.10.1.1 from official Ubuntu PPA (with all GNU
>> Radio and friends framework depending on 3.10 API). So first I have tried
>> to build from sources 3.10.1.1 tag https://github.com/EttusRe
>> search/uhd/tree/release_003_010_001_001 with different timeouts. So
>> relative constant in this version is GPS_COMM_TIMEOUT_MS used at
>> https://github.com/EttusResearch/uhd/blob/release_003_010_
>> 001_001/host/lib/usrp/gps_ctrl.cpp#L209 I changed it's value from 1300
>> to 10000. I also tried changing GPS_TIMEOUT_DELAY_MS
>> and GPSDO_COMMAND_DELAY_MS from 200 ms to 1000 ms (just in case). It turns
>> out that if GPS_COMM_TIMEOUT_MS value is increased GPSDO is detected as
>> "generic NMEA GPS device", but it does not work:
>>
>> $ ./sync_to_gps
>> ...
>> -- Detecting internal GPSDO.... Found a generic NMEA GPS device
>> ...
>> UHD Warning:
>> locked: ValueError: gps ctrl: No GPGGA message found
>>
>> UHD Warning:
>> locked: ValueError: gps ctrl: No GPGGA message found
>>
>> UHD Warning:
>> locked: ValueError: gps ctrl: No GPGGA message found
>>
>> Error: ValueError: locked(): unable to determine GPS lock statusThis
>> could mean that you have
>> not installed the GPSDO correctly.
>>
>> Then I have built UHD from the master branch (3.11). In this version in
>> gps_ctrl.cpp at 210 line the timeout is hardcoded to 650 ms which is twice
>> as less than GPS_COMM_TIMEOUT_MS = 1300 used in 3.10. But using the master
>> branch GPSDO is detected and works just OK without any modifications. I
>> have not done any code inspection of the differences between 3.10.1.1 and
>> 3.11 master version. But it seems that the issue is fixed in the master
>> branch. I would appreciate (and may be others too) if the fix is backported
>> to the 3.10 branch as it is current stable release.
>>
>>
>> 2017-03-01 22:24 GMT+03:00 Michael West <[email protected]>:
>>
>>> When using PCIe, the FPGA image is reloaded. That causes a reset of the
>>> GPSDO. The changes in the commit attempted to wait long enough for the
>>> GPSDO firmware to initialize, but not so long as to slow down device
>>> initialization if no GPSDO was present. You can try increasing the timeout
>>> on this line to see if it fixes the issue:
>>> https://github.com/EttusResearch/uhd/blob/master/host/lib/us
>>> rp/gps_ctrl.cpp#L210
>>>
>>> Regards,
>>> Michael
>>>
>>> On Tue, Feb 28, 2017 at 1:57 AM, Roman Olesyuk <[email protected]>
>>> wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> I use the latest UHD and FPGA image 3.10.1.1 and still experiece this
>>>> issue. My OS is Ubuntu 16.04.2, kernel 4.4.0-64-generic #85 x86_64, NI RIO
>>>> drivers 15.0.0. In addition I have unstable PPS/GPS LOCK behavior as
>>>> desribed in my previous email (e.g. stable PPS/GPS LOCK only when PC with
>>>> PCIe card is power off).
>>>>
>>>> --
>>>> ? ?????????, ????? ??????.
>>>> Yours sincerely, Roman Olesyuk.
>>>>
>>>>
>>>> 28 ????. 2017 ?. 10:33 ???????????? "Nikita Airee" <
>>>> [email protected]> ???????:
>>>>
>>>> No Roman, I don't see such a behaviour in my USRP. Because in my case
>>>> the GPS refuses to lock but the PPS works fine blinking every second. Did
>>>> you try the patch? Does it work for you?
>>>>
>>>> Michael, thanks for your suggestion! But it seems like it is not
>>>> working for me. It is entirely possible that I may be doing something wrong
>>>> because I have never patched a commit before. But the gps_ctrl.cpp file
>>>> does change at its location <working directory>/uhd/host/usrp/.
>>>>
>>>> Also for when the gpsdo does work, ie with Ethernet, how do I get this
>>>> gpsdo to lock? I suppose simply running sync_to_gps should time and
>>>> reference lock my gpsdo?
>>>>
>>>> Bests,
>>>> Nikita
>>>>
>>>>
>>>> On Tue, Feb 28, 2017 at 4:06 AM, Michael West <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Nikita,
>>>>>
>>>>> Sadly, we know what this issue is. We sped up the X300 initialization
>>>>> so much that the firmware on the GPSDO does not have time to finish
>>>>> initializing before the detection code runs. The problem was fixed in the
>>>>> 3.10.1.1 release, but for some reason the fix did not get applied to the
>>>>> 3.9.6 release. The specific commit that is needed is
>>>>> https://github.com/EttusResearch/uhd/commit/63fcfb9574d64797
>>>>> b807a0dd356f5d7bfc48f082
>>>>>
>>>>> You can try to patch with that commit until we get it properly fixed.
>>>>> We should have it fixed on the LTS branch soon.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Mon, Feb 27, 2017 at 12:27 PM, Roman Olesyuk via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Nikita,
>>>>>>
>>>>>> I experience the same issue. In addition I observe the following
>>>>>> behavior. I checked LEDs on GPSDO board. Two green LEDs are on for
>>>>>> several seconds when I power on X310 and then they go off. If the PCIe
>>>>>> connector is plugged in, but PC is powered off, in about 30-60 seconds I
>>>>>> observe that PPS LED starts blinking once per seconds, and after about 10
>>>>>> minutes GPS LOCK LED (on GPSDO boards and on the front panel) goes on.
>>>>>> This
>>>>>> is very stable behavior when PCIe IS PLUGGED IN, BUT PC IS OFF. I can get
>>>>>> very stable GPS lock (the LED is on as long as I can observe) and PPS is
>>>>>> always blinking. If I use 1Gbps network connection (with PCIe connector
>>>>>> unplugged) or if I use PCIe connection (just power on X310, then power on
>>>>>> PC), I do not see PPS blinking even after several minutes. Sometimes PPS
>>>>>> LED goes blinking and after 10-60 seconds it goes off again. Very rarely
>>>>>> I
>>>>>> can see PPS blinking for several minutes and GPS LOCK LED is even rarer
>>>>>> (almost never see it). The behaviors are almost the same in PCIe and
>>>>>> 1Gbps
>>>>>> modes. So it looks for me like some FPGA/GPSDO initialization problem.
>>>>>>
>>>>>> Can you confirm my observations?
>>>>>>
>>>>>> --
>>>>>> Yours sincerely, Roman Olesyuk.
>>>>>>
>>>>>> 2017-02-27 13:43 GMT+03:00 Nikita Airee via USRP-users <
>>>>>> [email protected]>:
>>>>>>
>>>>>>> Hi list,
>>>>>>>
>>>>>>> the information I had provided might not have been enough. So here
>>>>>>> is some more:
>>>>>>>
>>>>>>> My X310 has internal GPSDO. This is visible to UHD when I perform
>>>>>>> uhd_usrp_probe provided it is connected to my laptop using Gigabit
>>>>>>> ethernet:
>>>>>>>
>>>>>>> linux; GNU C++ version 4.8.4; Boost_106000;
>>>>>>> UHD_003.009.006-0-g122d5f8e
>>>>>>>
>>>>>>> -- X300 initialization sequence...
>>>>>>> -- Determining maximum frame size... 1472 bytes.
>>>>>>> -- Setup basic communication...
>>>>>>> -- Loading values from EEPROM...
>>>>>>> -- Setup RF frontend clocking...
>>>>>>> -- Radio 1x clock:200
>>>>>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>>>>>> Firmware Rev 0.929a*
>>>>>>> -- Initialize Radio0 control...
>>>>>>> -- Performing register loopback test... pass
>>>>>>> -- Initialize Radio1 control...
>>>>>>> -- Performing register loopback test... pass
>>>>>>> ...
>>>>>>>
>>>>>>> However, when I use PCI Express for connection, it says:
>>>>>>>
>>>>>>> linux; GNU C++ version 4.8.4; Boost_106000;
>>>>>>> UHD_003.009.006-0-g122d5f8e
>>>>>>>
>>>>>>> -- X300 initialization sequence...
>>>>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>>>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>>>>>> rp_x310_fpga_HGS.lvbitx...
>>>>>>> -- Setup basic communication...
>>>>>>> -- Loading values from EEPROM...
>>>>>>> -- Setup RF frontend clocking...
>>>>>>> -- Radio 1x clock:200
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> *Detecting internal GPSDO.... UHD Error: GPS invalid reply "",
>>>>>>> assuming none availableNo GPSDO found*
>>>>>>> -- Initialize Radio0 control...
>>>>>>> -- Performing register loopback test... pass
>>>>>>> -- Initialize Radio1 control...
>>>>>>> -- Performing register loopback test... pass
>>>>>>> ...
>>>>>>>
>>>>>>> When the same USRP is connected to a laptop with a different UHD
>>>>>>> version via PCIe, I get:
>>>>>>>
>>>>>>> linux; GNU C++ version 4.8.2; Boost_106000;
>>>>>>> UHD_3.11.0.git-28-gc66cb1ba
>>>>>>>
>>>>>>> -- X300 initialization sequence...
>>>>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>>>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>>>>>> rp_x310_fpga_HG.lvbitx...
>>>>>>> -- Setup basic communication...
>>>>>>> -- Loading values from EEPROM...
>>>>>>> -- Setup RF frontend clocking...
>>>>>>> -- Radio 1x clock:200
>>>>>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>>>>>> Firmware Rev 0.929a*
>>>>>>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput:
>>>>>>> 1186.1MB/s)
>>>>>>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput:
>>>>>>> 1189.4MB/s)
>>>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>>>>> -- Performing timer loopback test... pass
>>>>>>> -- Performing timer loopback test... pass
>>>>>>> ...
>>>>>>>
>>>>>>> Also when I try sync_to_gps, it says:
>>>>>>> ...
>>>>>>> Waiting for reference lock...LOCKED
>>>>>>> *WARNING: GPS not locked - time will not be accurate until locked *
>>>>>>> USRP time: 1136078288.000000000
>>>>>>> GPSDO time: 1136078288.000000000
>>>>>>>
>>>>>>> SUCCESS: USRP time synchronized to GPS time
>>>>>>>
>>>>>>> On querying gpsdo sensors soon after, I find that :
>>>>>>>
>>>>>>> USRP Locked to GPSDO 10 MHz Reference.
>>>>>>>
>>>>>>> GPS and UHD Device time are NOT aligned;
>>>>>>> last_pps: 9 vs gps: 1136078227. Trying to set the device time to GPS
>>>>>>> time...
>>>>>>> -- 1) catch time transition at pps edge
>>>>>>> -- 2) set times next pps (synchronously)
>>>>>>> last_pps: 1136078231 vs gps: 1136078231.
>>>>>>> GPS and UHD Device time are aligned.
>>>>>>> Printing available NMEA strings:
>>>>>>> GPS_GPGGA: $GPGGA,011711.00,0000.0000,N,0
>>>>>>> 0000.0000,E,0,99,1.0,0.0,M,0.0,M,,*5B
>>>>>>> GPS_GPRMC: $GPRMC,011711.00,V,0000.0000,N
>>>>>>> ,00000.0000,E,0.0,0.0,010106,,*25
>>>>>>> GPS Epoch time at last PPS: 1136078232.00000 seconds
>>>>>>> UHD Device time last PPS: 1136078232.00000 seconds
>>>>>>> UHD Device time right now: 1136078232.27291 seconds
>>>>>>> PC Clock time: 1487756260 seconds
>>>>>>> ...
>>>>>>>
>>>>>>> Could anybody please help me with this? I suppose that when the gps
>>>>>>> is locked, it means that uhd is time aligned with gps? If so, I would
>>>>>>> also
>>>>>>> really like to know exactly how you permanently lock gps.
>>>>>>>
>>>>>>> Bests,
>>>>>>> Nikita Airee
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 21, 2017 at 8:20 PM, Nikita Airee <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi list,
>>>>>>>>
>>>>>>>> I have:
>>>>>>>>
>>>>>>>> Ubuntu 14.04
>>>>>>>>
>>>>>>>> UHD: 003.009.006-0-g122d5f8e
>>>>>>>>
>>>>>>>> USRP X310 with CBX20 + GPSDO
>>>>>>>>
>>>>>>>> I moved to UHD 3.9.6 very recently and since then have been facing the
>>>>>>>> following issue related to GPSDO:
>>>>>>>>
>>>>>>>> *UHD Error: GPS invalid reply "", assuming none available
>>>>>>>> No GPSDO found*
>>>>>>>>
>>>>>>>> UHD_3.11.0.git-28-gc66cb1ba would never throw up this message.
>>>>>>>>
>>>>>>>> Is this a known issue? If not, how do I use GPSDO?
>>>>>>>>
>>>>>>>> Bests,
>>>>>>>>
>>>>>>>> Nikita Airee
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ? ?????????, ????? ??????.
>>>>>> Yours sincerely, Roman Olesyuk.
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> ? ?????????, ????? ??????.
>> Yours sincerely, Roman Olesyuk.
>>
>
>
--
? ?????????, ????? ??????.
Yours sincerely, Roman Olesyuk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170309/55d9d5a6/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 9 Mar 2017 13:52:36 -0500
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] custom RFNoC flowgraph seg faulting after update
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I updated all of my packages yesterday (gnuradio, rfnoc, etc) and now my
flowgraph with my custom block segfaults when I run it (it ran fine
before the updates).
*I ran: ulimit -c unlimited
*then, ./CPremoval.py
*this creates a file named core (there is no PID extension on it like
the wiki says there will be).
*I then run: gdp python2 core, and 'bt' at the prompt when it comes up.
The output looks like this:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python2 ./CPremoval.py'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007ff351094195 in uhd::rfnoc::block_ctrl_base::clear (
this=this@entry=0x2d4e680)
at /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/block_ctrl_base.cpp:417
#2 0x00007ff35109d606 in uhd::rfnoc::block_ctrl_base::block_ctrl_base (
this=0x2d4e680, __vtt_parm=<optimized out>, make_args=...,
__in_chrg=<optimized out>)
at /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/block_ctrl_base.cpp:78
#3 0x00007ff350a9440e in
cpremoval_block_ctrl_make(uhd::rfnoc::make_args_t const&) () from
/home/jmat/rfnoc/lib/libgnuradio-multiaperture.so
#4 0x00007ff350a947bc in
boost::detail::function::function_invoker1<boost::shared_ptr<uhd::rfnoc::block_ctrl_base>
(*)(uhd::rfnoc::make_args_t const&),
boost::shared_ptr<uhd::rfnoc::block_ctrl_base>, uhd::rfnoc::make_args_t
const&>::invoke(boost::detail::function::function_buffer&,
uhd::rfnoc::make_args_t const&) ()
from /home/jmat/rfnoc/lib/libgnuradio-multiaperture.so
#5 0x00007ff3510ad3a0 in operator() (a0=..., this=<optimized out>)
at /usr/include/boost/function/function_template.hpp:767
#6 uhd::rfnoc::block_ctrl_base::make (make_args_=..., noc_id=<optimized
out>)
at
/home/jmat/rfnoc/src/uhd/host/lib/rfnoc/block_ctrl_base_factory.cpp:94
#7 0x00007ff35134b0a3 in uhd::usrp::device3_impl::enumerate_rfnoc_blocks (
this=this@entry=0x2b976f0, device_index=0, n_blocks=n_blocks@entry=8,
base_port=base_port@entry=3, base_sid=..., transport_args=...)
---Type <return> to continue, or q <return> to quit---
at /home/jmat/rfnoc/src/uhd/host/lib/usrp/device3/device3_impl.cpp:175
#8 0x00007ff35145df9d in x300_impl::setup_mb (this=this@entry=0x2b976f0,
mb_i=mb_i@entry=0, dev_addr=...)
at /home/jmat/rfnoc/src/uhd/host/lib/usrp/x300/x300_impl.cpp:975
#9 0x00007ff3514626ec in x300_impl::x300_impl (this=0x2b976f0,
dev_addr=...)
at /home/jmat/rfnoc/src/uhd/host/lib/usrp/x300/x300_impl.cpp:397
#10 0x00007ff351462b82 in x300_make (device_addr=...)
at /home/jmat/rfnoc/src/uhd/host/lib/usrp/x300/x300_impl.cpp:350
#11 0x00007ff35139cc6c in
boost::detail::function::function_invoker1<boost::shared_ptr<uhd::device>
(*)(uhd::device_addr_t const&), boost::shared_ptr<uhd::device>,
uhd::device_addr_t const&>::invoke (function_ptr=..., a0=...)
at /usr/include/boost/function/function_template.hpp:95
#12 0x00007ff3515b4869 in operator() (a0=..., this=0x7fff8d066880)
at /usr/include/boost/function/function_template.hpp:767
#13 uhd::device::make (hint=..., filter=<optimized out>, which=0)
at /home/jmat/rfnoc/src/uhd/host/lib/device.cpp:169
#14 0x00007ff3519fb632 in device3_impl (device_addr=..., this=0x2b96b90)
at /home/jmat/rfnoc/src/gr-ettus/lib/device3.cc:41
#15 gr::ettus::device3::make (device_addr=...)
at /home/jmat/rfnoc/src/gr-ettus/lib/device3.cc:90
#16 0x00007ff351ca528d in _wrap_device3_make (args=<optimized out>,
kwargs=<optimized out>)
at
/home/jmat/rfnoc/src/gr-ettus/build/swig/ettus_swigPYTHON_wrap.cxx:2---Type
<return> to continue, or q <return> to quit---
0430
#17 0x000000000052714b in PyEval_EvalFrameEx ()
#18 0x0000000000555551 in PyEval_EvalCodeEx ()
#19 0x0000000000525560 in PyEval_EvalFrameEx ()
#20 0x0000000000568b3a in ?? ()
#21 0x00000000004c2604 in ?? ()
#22 0x00000000004d1c5c in ?? ()
#23 0x000000000055f6db in ?? ()
#24 0x00000000005244dd in PyEval_EvalFrameEx ()
#25 0x0000000000555551 in PyEval_EvalCodeEx ()
#26 0x0000000000524338 in PyEval_EvalFrameEx ()
#27 0x0000000000567d14 in ?? ()
#28 0x0000000000465bf4 in PyRun_FileExFlags ()
#29 0x000000000046612d in PyRun_SimpleFileExFlags ()
#30 0x0000000000466d92 in Py_Main ()
#31 0x00007ff3868b6f45 in __libc_start_main (main=0x466e50 <main>, argc=2,
argv=0x7fff8d068438, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fff8d068428) at
libc-start.c:287
#32 0x0000000000577c2e in _start ()
I couldn't glean anything from that, is someone else able to?
------------------------------
Message: 5
Date: Thu, 9 Mar 2017 14:01:11 -0500
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] custom RFNoC flowgraph seg faulting after
update
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Never mind, I am an idiot (again). I didn't rebuild my rfnoc block's
library after updating everything. So after a (for anyone else who runs
into this problem):
*cd ~/rfnoc-mulitiaperture/build
*make uninstall
*make clean
*make
*make install
*sudo ldconfig
*and a reload of gnuradio
It runs again. What clued me in was the gdb line: #3 0x00007ff350a9440e
in cpremoval_block_ctrl_make(uhd::rfnoc::make_args_t const&) () from
/home/jmat/rfnoc/lib/libgnuradio-multiaperture.so
On 03/09/2017 01:52 PM, Jason Matusiak wrote:
> I updated all of my packages yesterday (gnuradio, rfnoc, etc) and now
> my flowgraph with my custom block segfaults when I run it (it ran fine
> before the updates).
>
> *I ran: ulimit -c unlimited
> *then, ./CPremoval.py
> *this creates a file named core (there is no PID extension on it like
> the wiki says there will be).
> *I then run: gdp python2 core, and 'bt' at the prompt when it comes up.
>
> The output looks like this:
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `python2 ./CPremoval.py'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x0000000000000000 in ?? ()
> (gdb) bt
> #0 0x0000000000000000 in ?? ()
> #1 0x00007ff351094195 in uhd::rfnoc::block_ctrl_base::clear (
> this=this@entry=0x2d4e680)
> at /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/block_ctrl_base.cpp:417
> #2 0x00007ff35109d606 in uhd::rfnoc::block_ctrl_base::block_ctrl_base (
> this=0x2d4e680, __vtt_parm=<optimized out>, make_args=...,
> __in_chrg=<optimized out>)
> at /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/block_ctrl_base.cpp:78
> #3 0x00007ff350a9440e in
> cpremoval_block_ctrl_make(uhd::rfnoc::make_args_t const&) () from
> /home/jmat/rfnoc/lib/libgnuradio-multiaperture.so
> #4 0x00007ff350a947bc in
> boost::detail::function::function_invoker1<boost::shared_ptr<uhd::rfnoc::block_ctrl_base>
>
> (*)(uhd::rfnoc::make_args_t const&),
> boost::shared_ptr<uhd::rfnoc::block_ctrl_base>,
> uhd::rfnoc::make_args_t
> const&>::invoke(boost::detail::function::function_buffer&,
> uhd::rfnoc::make_args_t const&) ()
> from /home/jmat/rfnoc/lib/libgnuradio-multiaperture.so
> #5 0x00007ff3510ad3a0 in operator() (a0=..., this=<optimized out>)
> at /usr/include/boost/function/function_template.hpp:767
> #6 uhd::rfnoc::block_ctrl_base::make (make_args_=...,
> noc_id=<optimized out>)
> at
> /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/block_ctrl_base_factory.cpp:94
> #7 0x00007ff35134b0a3 in
> uhd::usrp::device3_impl::enumerate_rfnoc_blocks (
> this=this@entry=0x2b976f0, device_index=0, n_blocks=n_blocks@entry=8,
> base_port=base_port@entry=3, base_sid=..., transport_args=...)
> ---Type <return> to continue, or q <return> to quit---
> at
> /home/jmat/rfnoc/src/uhd/host/lib/usrp/device3/device3_impl.cpp:175
> #8 0x00007ff35145df9d in x300_impl::setup_mb (this=this@entry=0x2b976f0,
> mb_i=mb_i@entry=0, dev_addr=...)
> at /home/jmat/rfnoc/src/uhd/host/lib/usrp/x300/x300_impl.cpp:975
> #9 0x00007ff3514626ec in x300_impl::x300_impl (this=0x2b976f0,
> dev_addr=...)
> at /home/jmat/rfnoc/src/uhd/host/lib/usrp/x300/x300_impl.cpp:397
> #10 0x00007ff351462b82 in x300_make (device_addr=...)
> at /home/jmat/rfnoc/src/uhd/host/lib/usrp/x300/x300_impl.cpp:350
> #11 0x00007ff35139cc6c in
> boost::detail::function::function_invoker1<boost::shared_ptr<uhd::device>
> (*)(uhd::device_addr_t const&), boost::shared_ptr<uhd::device>,
> uhd::device_addr_t const&>::invoke (function_ptr=..., a0=...)
> at /usr/include/boost/function/function_template.hpp:95
> #12 0x00007ff3515b4869 in operator() (a0=..., this=0x7fff8d066880)
> at /usr/include/boost/function/function_template.hpp:767
> #13 uhd::device::make (hint=..., filter=<optimized out>, which=0)
> at /home/jmat/rfnoc/src/uhd/host/lib/device.cpp:169
> #14 0x00007ff3519fb632 in device3_impl (device_addr=..., this=0x2b96b90)
> at /home/jmat/rfnoc/src/gr-ettus/lib/device3.cc:41
> #15 gr::ettus::device3::make (device_addr=...)
> at /home/jmat/rfnoc/src/gr-ettus/lib/device3.cc:90
> #16 0x00007ff351ca528d in _wrap_device3_make (args=<optimized out>,
> kwargs=<optimized out>)
> at
> /home/jmat/rfnoc/src/gr-ettus/build/swig/ettus_swigPYTHON_wrap.cxx:2---Type
> <return> to continue, or q <return> to quit---
> 0430
> #17 0x000000000052714b in PyEval_EvalFrameEx ()
> #18 0x0000000000555551 in PyEval_EvalCodeEx ()
> #19 0x0000000000525560 in PyEval_EvalFrameEx ()
> #20 0x0000000000568b3a in ?? ()
> #21 0x00000000004c2604 in ?? ()
> #22 0x00000000004d1c5c in ?? ()
> #23 0x000000000055f6db in ?? ()
> #24 0x00000000005244dd in PyEval_EvalFrameEx ()
> #25 0x0000000000555551 in PyEval_EvalCodeEx ()
> #26 0x0000000000524338 in PyEval_EvalFrameEx ()
> #27 0x0000000000567d14 in ?? ()
> #28 0x0000000000465bf4 in PyRun_FileExFlags ()
> #29 0x000000000046612d in PyRun_SimpleFileExFlags ()
> #30 0x0000000000466d92 in Py_Main ()
> #31 0x00007ff3868b6f45 in __libc_start_main (main=0x466e50 <main>,
> argc=2,
> argv=0x7fff8d068438, init=<optimized out>, fini=<optimized out>,
> rtld_fini=<optimized out>, stack_end=0x7fff8d068428) at
> libc-start.c:287
> #32 0x0000000000577c2e in _start ()
>
>
> I couldn't glean anything from that, is someone else able to?
------------------------------
Message: 6
Date: Fri, 10 Mar 2017 11:27:32 +0100
From: Paolo Palana <[email protected]>
To: Sylvain Munaut <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] axi_wrapper with simple_mode=0... help me
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear Sylvain,
Thank you for you suggestion.
I looked more carefully on axi_wrapper code and I found what i did wrong.
The truth is that I made a bad assumption from the beginning, namely
that the chdr coming from the axi_wrapper had the src_sid and dst_sid
properly set,
it was wrong indeed.
I missed also the noc_shell output ports
.src_sid(src_sid), // SID of this block
.next_dst_sid(next_dst_sid), // Next destination SID
So I used these values as src_sid and dst_sid for "my" header and now,
it works.
To talk in veriglog:
//DECODE THE INCOMING HEADER
cvita_hdr_decoder cvita_hdr_decoder (
.header(int_header_from_axiw),
.pkt_type(int_pkt_type_from_axiw),
.eob(int_eob_from_axiw),
.has_time(int_has_time_from_axiw),
.seqnum(int_seqnum_from_axiw),
.length(int_len_from_axiw),
.payload_length(int_payload_len_from_axiw),
.src_sid(int_src_sid_from_axiw),
.dst_sid(int_dst_sid_from_axiw),
.vita_time(int_vita_taime_from_axiw)
);
//ENCODE THE OUTGOING HEADER
cvita_hdr_encoder cvita_hdr_encoder (
.pkt_type(int_pkt_type_from_axiw),
.eob(int_eob_from_axiw),
.has_time(int_has_time_from_axiw),
.seqnum(int_seqnum_from_axiw),
.payload_length(int_payload_len_from_axiw),
.src_sid(int_src_sid_from_axiw),
.dst_sid(next_dst_sid), <--- this is
the important one
.vita_time(int_vita_taime_from_axiw),
.header(int_header_to_axiw)
);
Thank you again and have a good day
Paolo
------------------------------
Message: 7
Date: Fri, 10 Mar 2017 15:18:40 +0100
From: Sumit Kumar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310 : Error code -63150
Message-ID:
<CAOExtcQ6Zb4HjK-t-BsMTwJgqUq1f6A=CsO06OKjywNVk38s=g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
When I run ./uhd_usrp_probe, I see the following error :
Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown
error. (Error code -63150)
*System Details : linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.009.004-0-g2b5a88bb*
Regards
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170310/4cb886be/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 10 Mar 2017 12:07:35 -0300
From: Rub?n Vogel <[email protected]>
To: [email protected]
Subject: [USRP-users] [IMAGE][FPGA] LUT's problem
Message-ID:
<cam7gm7bq7wwvuevjcdrlimimros9e+etofgfn6bv6skmjhx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I am trying to create a fpga image for Ettus E310, using Xilinx Vivado
2015.4, with the following blocks:
--windows
--axi_dma_fifo
--fft
Using the follow command:
sudo python uhd_image_builder.py fft window axi_dma_fifo -d E310 -t
E310_RFNOC -g -c --fill-with-fifos
But during block synthesis, I get this error:
Time (s): cpu = 00:11:33 ; elapsed = 00:09:28 . Memory (MB): peak =
8470.406 ; gain = 0.000 ; free physical = 3094 ; free virtual = 44037
ERROR: [Place 30-484] The packing of lutram instances into lutram capable
slices could not be obeyed.
Number of LUTRAMs: 17168
Theoretically, assuming any two LUTRAMs can be packed into a slice, the
number of LUTRAM capable slices required is 4292 out of 4350 in the device
(utilization 98.6667%)
Actual number of LUTRAM capable slices required is 4373 out of 4350 in
the device (utilization 100.529%).
As a result, 20 or more LUTRAMs failed to place.
Names of the first 20 LUTRAMs:
zynq_fifo_top0/s2h_arbiter/stream_circuit[5].sts_fifo/fifo_short/gen_srlc32e[3].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[5].sts_fifo/fifo_short/gen_srlc32e[4].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[5].sts_fifo/fifo_short/gen_srlc32e[5].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[5].sts_fifo/fifo_short/o_tdata_reg[0]
type FDRE
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_addr_fifo/fifo_short/gen_srlc32e[30].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_addr_fifo/fifo_short/gen_srlc32e[5].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_addr_fifo/fifo_short/gen_srlc32e[8].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_addr_fifo/fifo_short/gen_srlc32e[9].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_size_fifo/fifo_short/gen_srlc32e[12].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_size_fifo/fifo_short/gen_srlc32e[15].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_size_fifo/fifo_short/gen_srlc32e[22].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_size_fifo/fifo_short/gen_srlc32e[2].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_size_fifo/fifo_short/gen_srlc32e[3].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_size_fifo/fifo_short/gen_srlc32e[4].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[6].crl_size_fifo/fifo_short/gen_srlc32e[8].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[7].crl_addr_fifo/fifo_short/gen_srlc32e[23].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[7].crl_addr_fifo/fifo_short/gen_srlc32e[24].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[7].crl_addr_fifo/fifo_short/gen_srlc32e[27].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[7].crl_addr_fifo/fifo_short/gen_srlc32e[28].srlc32e
type SRLC32E
zynq_fifo_top0/s2h_arbiter/stream_circuit[7].crl_addr_fifo/fifo_short/gen_srlc32e[30].srlc32e
type SRLC32E
None of mentioned LUTRAMs is from any Pblock.
Resolution: Please analyze your design to determine if the number of
lutrams can be reduced by combining multiple lutrams into Block RAMs for
example.
ERROR: [Place 30-99] Placer failed with error: 'Could not place all lutrams'
Please review all ERROR, CRITICAL WARNING, and WARNING messages during
placement to understand the cause for failure.
Ending Placer Task | Checksum: 113c459bc
Time (s): cpu = 00:11:33 ; elapsed = 00:09:28 . Memory (MB): peak =
8470.406 ; gain = 0.000 ; free physical = 3094 ; free virtual = 44037
INFO: [Common 17-83] Releasing license: Implementation
40 Infos, 82 Warnings, 18 Critical Warnings and 3 Errors encountered.
place_design failed
ERROR: [Common 17-69] Command failed: Placer could not place all instances
Reading this error, I conclude that there is not enough space in the fpga
to load all the blocks. But when I download the images developed by Ettus
using 'uhd-images-downloader' and run 'uhd-usrp-probe', I see that the
rfnoc image has 6 rfnoc blocks. I do not understand how I can not create an
image with 3 rfnoc blocks. I hope you can help me, regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170310/6863ad50/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 79, Issue 10
******************************************
