Classification: UK OFFICIAL
Update.
A 1rx1tx version got past the problem I was having with both the rx and tx test.
It then got stuck on the "min" test for sample rate and would timeout every time. This has happened to me before every few runs of the test, but now it is every single time.
This is listed as a known defect of the AD9361 library (mentioned in the test documentation:
https://opencpi.github.io/assets/FMCOMMS_2_3_Tx_Test.pdf).
I commented this specific test out and the rest of the tests "PASSED" with a return of 0.
I'm pretty sure having 2rx will always cause the rx test to fail, and having 2tx will always cause the tx test to fail (the opposite may also be true with 2rx failing the tx test, and 2tx failing the rx test).
I think this is due to the xml applications that it runs (app_default_fmcomms_2/3, app_rx/tx_corruption_fmcomms_2/3) only instancing one set of rx and tx components.
Somehow this allows the 72 value to be incorrectly used as a default for the second channels rf_gain.
It'd be unreasonable of me to suggest that the test should be amended as it'd be somewhat obnoxious to have to cover all of the configuration cases for the fmcomms device workers.
However, I'd like to suggest that the documentation for both tests (fmcomms_2_3_rx_test, fmcomms_2_3_tx_test) be amended to specify that it requires a 1rx_1tx container.
For example, replacing the following bullet point under the "Prerequisites" heading:
- * empty assembly with one of the *fmcomms_2_3* containers for the desired HDL platform
+ * empty assembly with a *1rx_1tx*fmcomms_2_3* container for the desired HDL platform
It's possible that a 1rx_2tx may pass the rx test, and a 2rx_1tx may pass the tx test (if I get some time I might test this).
Any suggestions as to why I might be getting this API timeout every time now, as opposed to once every couple of tries?
Can I safely ignore this as it is an expected defect?
-----Original Message-----
From: discuss <discuss-bounces_at_lists.opencpi.org> On Behalf Of Walters Dominic A via discuss
Sent: 07 January 2020 09:14
To: Davis Hoover <dhoover_at_geontech.com>; discuss_at_lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Fwd: [UK OFFICIAL] FMCOMMS 3 RX/TX Test
Classification: UK OFFICIAL
I am using almost exactly this config file for my empty assembly:
https://scanmail.trustwave.com/?c=7369&d=ksyU3t3lK75_XeNuPv2gyrvGsG093IQKdMC3eA2LuA&u=https%3a%2f%2fgithub%2ecom%2fGeontech%2fopencpi%2fblob%2frelease%5f1%2e4%5fzynq%5fultra%2fprojects%2fassets%2fhdl%2fplatforms%2fzed%2fcfg%5f2rx%5f2tx%5ffmcomms%5f2%5f3%5flpc%5flvds%2exml
So 2 ADCs, 2 DACs, an ADC sub, and a DAC sub.
I have noticed that in the xml applications that the fmcomms_rx/tx_test runs it uses "Instances" of some of the components:
https://scanmail.trustwave.com/?c=7369&d=ksyU3t3lK75_XeNuPv2gyrvGsG093IQKdJ7iL1fdsQ&u=https%3a%2f%2fgithub%2ecom%2fGeontech%2fopencpi%2fblob%2frelease%5f1%2e4%5fzynq%5fultra%2fprojects%2fassets%2fapplications%2ffmcomms%5f2%5f3%5ftx%5ftest%2fapp%5frx%5fcorruption%5ffmcomms3%2exml
I haven't seen "Instances" before, however, I notice that it only ever creates one rxtx pair whereas I obviously will have two.
Is this a possible problem?
I'm building a 1rx1tx version this morning (GMT) and will see what kind of debug prints I get back out.
Thanks
-----Original Message-----
From: discuss <discuss-bounces_at_lists.opencpi.org> On Behalf Of Davis Hoover
Sent: 06 January 2020 17:58
To: discuss_at_lists.opencpi.org
Subject: [Discuss OpenCPI] Fwd: [UK OFFICIAL] FMCOMMS 3 RX/TX Test
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=ksyU3t3lK75_XeNuPv2gyrvGsG093IQKdJ6xLgjX6w&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=ksyU3t3lK75_XeNuPv2gyrvGsG093IQKdM22LlvfvQ&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=ksyU3t3lK75_XeNuPv2gyrvGsG093IQKdM6zfgjcuA&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 Tue Jan 07 2020 - 11:58:02 CST