No problem! We should be able to get to the bottom of this. How many of
each of the ad9361_dac and ad9361_adc workers are in the bitstream being
deployed?
---------- Forwarded message ---------
From: Walters Dominic A via discuss <discuss_at_lists.opencpi.org>
Date: Mon, Jan 6, 2020 at 11:26 AM
Subject: Re: [Discuss OpenCPI] [UK OFFICIAL] FMCOMMS 3 RX/TX Test
To: discuss_at_lists.opencpi.org <discuss_at_lists.opencpi.org>
Classification: UK OFFICIAL
Apologies for resurrecting an old thread.
I've gotten back to trying to get the fmcomms_2_3_rx/tx_test in the
assets/applications directory to work with the BSP I'm using.
If I turn on ocpi_debug for the AD9361_proxy_config.rcc I get the following
before the fmcomms_2_3_tx_test application fails:
> ...
> TEST: ensure no corruption of rx rf_gain_dB
> ...
> DEBUG: ad9361_config_proxy: libad9361 API call:
ad9361_set_rx_rf_gain(ad9361_phy, 0, 13)
> DEBUG: ad9361_config_proxy: libad9361 API call:
ad9361_set_rx_rf_gain(ad9361_phy, 1, 72)
> Invalid gain 72, supported range [-3 - 71]
> Unable to write gain tbl idx reg: 268
> FAILED
The program then exits with a 1.
It passes the first 5 sets of tests (defaults, min, max, FB_Clk_Delay,
Tx_Data_Delay) and then fails on the first "rx_value_corruption" test.
The test expects a value of 13 for "rf_gain_dB" and I assume these debug
prints are part of the initialisation of the test.
It appears that whilst it correctly initialises channel 0 with 13, it
initialises channel 1 with 72 (an invalid value, so the ad9361 api
complains ending the application).
As Davis said in the previous email, 72 is used in the "max" test to check
that applying that value as "rf_gain_dB" fails correctly.
Trying thefmcomms_2_3_rx_test fails in a similar fashion, except right at
the start in the "default" tests but in the same style:
> ...
> DEBUG: ad9361_config_proxy: libad9361 API call:
ad9361_set_rx_rf_gain(ad9361_phy, 0, 1)
> DEBUG: ad9361_config_proxy: libad9361 API call:
ad9361_set_rx_rf_gain(ad9361_phy, 1, 72)
> Invalid gain 72, supported range [-3 - 71]
> Unable to write gain tbl idx reg: 268
> FAILED
Again where channel 1 is set to an invalid value.
Is this likely to be a configuration problem (somewhere I should have
provided a number of channels and haven't)? Any suggestions?
Tomorrow I'm going to try building a version with only 1rx and 1tx to make
sure it is due to the second channel.
Thank you for any help you can give!
-----Original Message-----
From: discuss <discuss-bounces_at_lists.opencpi.org> On Behalf Of Davis Hoover
Sent: 26 November 2019 18:05
To: discuss_at_lists.opencpi.org
Subject: [Discuss OpenCPI] [UK OFFICIAL] FMCOMMS 3 RX/TX Test
The success criteria for this app is that the app executable itself returns
0 (if you run echo $? after running the app, you should see 0 printed out).
This criteria is documented in
https://scanmail.trustwave.com/?c=7369&d=0end3X8t-1ON1hlSLCk_5A0G1ABQnEJZ43DxBfW4Og&u=https%3a%2f%2fopencpi%2egithub%2eio%2fassets%2fFMCOMMS%5f2%5f3%5fRx%5fTest%2epdf
I suspect you are seeing the printouts that occur due to line 69 in
https://scanmail.trustwave.com/?c=7369&d=0end3X8t-1ON1hlSLCk_5A0G1ABQnEJZ4yP2BaawbA&u=https%3a%2f%2fgithub%2ecom%2fGeontech%2fopencpi%2fblob%2frelease%5f1%2e4%5fzynq%5fultra%2fprojects%2fassets%2fapplications%2ffmcomms%5f2%5f3%5frx%5ftest%2ftest%5fapp%5fmaxes%2eh
- which performs a test write with a manual gain of 72, which is *expected*
to fail in the given scenario, and should not prevent the exit status from
being 0.
If you do in fact have a non-zero exit status, then there are other
problems that need to be addressed.
---------- Forwarded message ---------
From: Walters Dominic A via discuss <discuss_at_lists.opencpi.org>
Date: Tue, Nov 26, 2019 at 3:44 AM
Subject: Re: [Discuss OpenCPI] [UK OFFICIAL] FMCOMMS 3 RX/TX Test
To: discuss_at_lists.opencpi.org <discuss_at_lists.opencpi.org>
Classification: UK OFFICIAL
I am using Geontech's 1.4 version (
https://scanmail.trustwave.com/?c=7369&d=0end3X8t-1ON1hlSLCk_5A0G1ABQnEJZ4yDzVfWzaQ&u=https%3a%2f%2fgithub%2ecom%2fGeontech%2fopencpi%2ftree%2frelease%5f1%2e4%5fzynq%5fultra%29
that enables OpenCPI for UltraScale+.
The test prints FAILED after the error message I posted in the first email:
invalid gain 72, supported range [-3 - 71] Unable to write gain tbl idx
reg: 268 Exception thrown: AD9361_config_proxy produced error during
execution:
ad9361_set_rx_rf_gain() returned -22.
The only "return" I get (I think) is this -22 before it says FAILED.
-----Original Message-----
From: discuss <discuss-bounces_at_lists.opencpi.org> On Behalf Of Davis Hoover
Sent: 25 November 2019 18:14
To: discuss_at_lists.opencpi.org
Subject: [Discuss OpenCPI] [UK OFFICIAL] FMCOMMS 3 RX/TX Test
What version of OpenCPI are you using? Are you getting a non-zero exit
status? These apps test command & control only, not data, so they are
unaffected by what is connected the FMCOMMS RF ports.
---------- Forwarded message ---------
From: Walters Dominic A via discuss <discuss_at_lists.opencpi.org>
Date: Mon, Nov 25, 2019 at 11:32 AM
Subject: [Discuss OpenCPI] [UK OFFICIAL] FMCOMMS 3 RX/TX Test
To: discuss_at_lists.opencpi.org <discuss_at_lists.opencpi.org>
Classification: UK OFFICIAL
Hi again,
Last week I asked for advice on getting an FMC slot working on a ZCU102.
I think I have the FMC slot on my board at least partially working, and
I've been running the "fmcomms_2_3_rx_test" and "fmcomms_2_3_tx_test" apps
to try it out.
Both tests run until they get to the first test in the
"test_app_rx_value_corruption.h" file, where it tries to set rx_rf_gain_db.
I'm getting the error message:
invalid gain 72, supported range [-3 - 71] Unable to write gain tbl idx
reg: 268 Exception thrown: AD9361_config_proxy produced error during
execution:
ad9361_set_rx_rf_gain() returned -22.
Any suggestions as to where I should go from here?
I should mention although I have the FMCOMMS card plugged into my board, I
currently lack the capacity to provide it a source (i.e. the actual rf
ports aren't attached to anything).
Could this be my problem?
Thank you for any advice you have,
Dominic Walters
Engineer
Counter Terrorism & Security (CTS) Division [dstl] Porton Down
"This e-mail and any attachment(s) is intended for the recipient only.
Its unauthorised use,
disclosure, storage or copying is not permitted. Communications with Dstl
are monitored and/or recorded for system efficiency and other lawful
purposes, including business intelligence, business metrics and training.
Any views or opinions expressed in this e-mail do not necessarily reflect
Dstl policy."
"If you are not the intended recipient, please remove it from your system
and notify the author of the email and centralenq_at_dstl.gov.uk"
Received on Mon Jan 06 2020 - 17:58:17 CST