no_OS ADRV9008-2 DMA_EXAMPLE not working

Hi maurizio.sonzogni@abe.it ,

As you can see, some features are disabled for ADRV9008-2 (https://github.com/analogdevicesinc/no-OS/blob/791d675b84b142b52e1c8207a8b67d63755d8152/projects/adrv9009/src/app/headless.c#L420), since this chip has no Rx input.

However, the HDL has all the components, including DMA connected to ORx (https://github.com/analogdevicesinc/hdl/blob/a806a6f6ecb46cc2a96d49f2f373a1d76a677065/projects/adrv9009/common/adrv9009_bd.tcl#L445), and this can be enabled in software in similar way as for ADRV9009, but with a different base address (specified in xparameters.h - "#define XPAR_AXI_ADRV9009_RX_OS_DMA_BASEADDR 0x9C440000"). You will also need RX_OS_CORE enabled.

Regards,

George

Hi danmois,

thank you for your reply, but I cannot find how to enable RX_OS_CORE  in the software, and I cannot find structures for the observation channel to initialize (as the rx_dmac and rx_adc for the rx channel.

In any case I suppose that something must be output at the TX1 and/or TX2 outputs in this example.

Any suggestion?

Thank You

Maurizio Sonzogni

Hi George,

the problem is that the input data to the "tx_adrv9009_tpl_core" are always 0. if I put a VIO to set different values I see the correct output.

It seems that is the DMA chain that not working.

I'm now looking only the TX channel, so I don't think that the settings for the observation channel have impact on it.

Thank you

Maurizio

Hi maurizio.sonzogni@abe.it ,

Have you tried to set DDS for Tx (DMA example disabled) and use a spectrum analyzer to see the output frequencies?

Regards,

George

Hi maurizio.sonzogni@abe.it ,

We have done some testing, and found out that there could be a problematic component in the system, the offload FIFO. Bypassing it solved the problem of Tx DMA transfers for ADRV9009, and it should do the same for the chip you use (just that ORx is used instead of Rx, Tx remains the same).

Bypassing the offload FIFO is done by setting 1 in the function call below:

https://github.com/analogdevicesinc/no-OS/blob/1a29b0c3972a5abdb6afb205bda49b680e3bf2c7/projects/adrv9009/src/app/headless.c#L387

The Rx data in this case look right (external connection between Tx1 and Rx1):

Regards,

George

Hi George,

with your suggestion I can now se the correct output on both TX1 and TX2.

Remains a problem with the observation channels. I see that from the util_adrv9009_xcvr the first two channels (rx_0 and rx_1) are inactive, because they are related to te RX channels that are not present in the ADRV9008-2. The other two channels (rx_2 and rx_3) send something at the beginning, when fpga_xcvr_init is executed, but they stop at the axi_jesd204_rx_lane_clk_enable(rx_os_jesd) instruction in the talise_setup routine.

When the cannels are active I see the signals rx_charisk_2[3:0], rx_notintable_2[3:0], rx_disperr_2[3:0], rx_data_2[31:0] moving, but the signals rx_header_2[1:0] and rx_block_sync_2 are always stuck at 0.

From the block axi_adrv9009_rx_os_jesd the output signals rx_eof and rx_sof are always 0xF and the signals rx_data_tdata and rx_data_tvalid are always 0.

Finally at the instruction status = axi_dmac_transfer_wait_completion(rx_os_dmac, 500); the returned status is -1.

I don't know where to look for this problem: any suggestion?

Thank you

Maurizio

p.s.: I attach the console output and the settings of the transceiver parameters

Console.jpg   XCVR_Params.txt

Hi George,

I've noticed that in the console output there is this warning message:

warning: TAL_FRAMER_B status 0x29

Maybe this can explain that the OSRX channel is not working?

Thank you

Maurizio

Hi maurizio.sonzogni@abe.it ,

Here is the meaning of each bit:

https://github.com/analogdevicesinc/no-OS/blob/f841ca5b2e8f177c7efa76e2783ba7ba77cb57a9/drivers/rf-transceiver/talise/api/talise_jesd204.h#L261

Have you tried activating debug messages in no_os_print_log.h for receiving additional information about the program actions?

https://github.com/analogdevicesinc/no-OS/blob/f841ca5b2e8f177c7efa76e2783ba7ba77cb57a9/include/no_os_print_log.h#L55

#define NO_OS_LOG_LEVEL NO_OS_LOG_DEBUG

Regards,

George

Hi George,

this is the new console output with NO_OS_LOG_DEBUG log level.

DebugConsoleOutput.txt

Is there something wrong in the registers setting?

Thank you

Maurizio

P.S.: there is a mistake in the file

github.com/.../axi_adxcvr.c

prate does not exist, use parent_rate instead of *prate.

Hi George,

I solved the warning problem rebuilding from scratch the HDL project using the stable release 2021.2 instead of the last branch.

Anyway the OS channels are still wrong.

When executing the talise_setup command I see that the rx_valid goes stably high and the rx_data is other than 0 for a clock tick but after returns to 0 (see Fig1)

Fig1.jpg

Curiously the data begin to move when executing the TALISE_shutdown routine in the talise_shutdown routine in the main.

Also in this case the 32 MSBs remains stuck to 0.

Is it a problem of the OS channels and of the ADRV9008-2 that are non completely developed and tested in the no-OS environment?

I wonder if the no-OS application is aligned with the Linux one or the complete testing is done only on the Linux application. If I load the application provided with the demo board (that is Linux-based) I see the observation channels working right with the ADRV9009 Transceiver Evaluation Software.

Can you suggest some trial to identify the source of the problem?

Thank you

Maurizio

Hi maurizio.sonzogni@abe.it ,

The application for the ADRV9008-2 device is actually the application for the ADRV9009, with the Rx path disabled. We will take a look at the issue and get back to you as soon as possible regarding this.

My suggestion is to use the ADRV9009 HDL and the ADRV9009 project, modifying all the base addresses for the Rx with the ones from the Observation Rx from xparameters.h.

Thank you for signalling the problem in axi_adxcvr.c!

Regards,

George

Hi George,

I've replaced the RX_CORE_BASEADDR with the RX_OS_CORE_BASEADDR and the RX_DMA_BASEADDR with the RX_OS_DMA_BASEADDRbut i got the same behavior.

Now I see errors in the debug console output as you can see in the attachment:

Console_new.txt

I wonder if there is something to adjust in the default profile (the taliseInit_t talInit variable).

Thank you

Maurizio

Hi George,

I've replaced the RX_CORE_BASEADDR with the RX_OS_CORE_BASEADDR and the RX_DMA_BASEADDR with the RX_OS_DMA_BASEADDRbut i got the same behavior.

Now I see errors in the debug console output as you can see in the attachment:

Console_new.txt

I wonder if there is something to adjust in the default profile (the taliseInit_t talInit variable).

Thank you

Maurizio

Hi maurizio.sonzogni@abe.it ,

The displayed errors should not affect the functionality of the project. You could check also whether the ORx DMA transfer completes.

Regards,

George

Hi George.

the routine axi_dmac_transfer_wait_completion returns 0 so I think that that DMA transfer completes correctly.

After the Xil_DCacheInvalidateRange routine the (DDR_MEM_BASEADDR + 0x800000) memory space allocated for DMA is all 0 (I previously changed the content of this memory space): it seems that the 0 value I see in the ILA is written to the memory.

Thank you

Maurizio

Hi George,

I don't know what is changed but today the routine axi_dmac_transfer_wait_completion returns -1 (the bit AXI_DMAC_IRQ_SOT is = 1 but the bit AXI_DMAC_IRQ_EOT is = 0).

I don't know if it means something, but in the hdl project there are 11 methodology critical warnings:

Name Severity Details
All Violations (11)
Timing (11)
Bad Practice (11)
TIMING-6
TIMING #1 Critical Warning The clocks clk_fpga_0 and mmcm_clk_0_s_2 are related (timed together) but they have no common primary clock. The design could fail in hardware. To find a timing path between these clocks, run the following command: report_timing -from [get_clocks clk_fpga_0] -to [get_clocks mmcm_clk_0_s_2]
TIMING-7
TIMING #1 Critical Warning The clocks clk_fpga_0 and mmcm_clk_0_s_2 are related (timed together) but they have no common node. The design could fail in hardware. To find a timing path between these clocks, run the following command: report_timing -from [get_clocks clk_fpga_0] -to [get_clocks mmcm_clk_0_s_2]
TIMING-54
TIMING #1 Critical Warning A scoped Max Delay Datapath Only timing constraint is set between clocks clk_fpga_0 and clk_fpga_1 (see constraint position 294 in the Timing Constraint window in Vivado IDE). It is not recommended to define such scoped constraints between clocks as the constraint impacts timing paths outside of the scope.
TIMING #2 Critical Warning A scoped Max Delay Datapath Only timing constraint is set between clocks clk_fpga_0 and mmcm_clk_0_s_1 (see constraint position 348 in the Timing Constraint window in Vivado IDE). It is not recommended to define such scoped constraints between clocks as the constraint impacts timing paths outside of the scope.
TIMING #3 Critical Warning A scoped Max Delay Datapath Only timing constraint is set between clocks clk_fpga_0 and mmcm_clk_0_s_2 (see constraint position 405 in the Timing Constraint window in Vivado IDE). It is not recommended to define such scoped constraints between clocks as the constraint impacts timing paths outside of the scope.
TIMING #4 Critical Warning A scoped Max Delay Datapath Only timing constraint is set between clocks clk_fpga_1 and clk_fpga_1 (see constraint position 303 in the Timing Constraint window in Vivado IDE). It is not recommended to define such scoped constraints between clocks as the constraint impacts timing paths outside of the scope.
TIMING #5 Critical Warning A scoped Max Delay Datapath Only timing constraint is set between clocks clk_fpga_1 and clk_fpga_1 (see constraint position 307 in the Timing Constraint window in Vivado IDE). It is not recommended to define such scoped constraints between clocks as the constraint impacts timing paths outside of the scope.
TIMING #6 Critical Warning A scoped Max Delay Datapath Only timing constraint is set between clocks mmcm_clk_0_s_1 and clk_fpga_1 (see constraint position 357 in the Timing Constraint window in Vivado IDE). It is not recommended to define such scoped constraints between clocks as the constraint impacts timing paths outside of the scope.
TIMING #7 Critical Warning A scoped Max Delay Datapath Only timing constraint is set between clocks mmcm_clk_0_s_1 and clk_fpga_1 (see constraint position 364 in the Timing Constraint window in Vivado IDE). It is not recommended to define such scoped constraints between clocks as the constraint impacts timing paths outside of the scope.
TIMING #8 Critical Warning A scoped Max Delay Datapath Only timing constraint is set between clocks mmcm_clk_0_s_2 and clk_fpga_1 (see constraint position 414 in the Timing Constraint window in Vivado IDE). It is not recommended to define such scoped constraints between clocks as the constraint impacts timing paths outside of the scope.
TIMING #9 Critical Warning A scoped Max Delay Datapath Only timing constraint is set between clocks mmcm_clk_0_s_2 and clk_fpga_1 (see constraint position 421 in the Timing Constraint window in Vivado IDE). It is not recommended to define such scoped constraints between clocks as the constraint impacts timing paths outside of the scope.

Is there some example in Linux for the ADRV9008-2? Where to find out how to create it?

Thank you

Maurizio

Hi maurizio.sonzogni@abe.it ,

There is a Linux project for ADRV9008-2. The related files are on the Kuiper Linux folder zynq-zc706-adv7511-adrv9008-1-2.

Below you can see some files related to the project:

https://github.com/analogdevicesinc/linux/blob/master/arch/arm/boot/dts/zynq-zc706-adv7511-adrv9008-2-jesd204-fsm.dts

https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/adrv9009.c

Regards,

George

Hi George,

I've found that the DMA doesn't complete correctly because I've added an ILA to monitor the rx_phy0 and rx_phy1 signals at the input of the axi_adrv9009_rx_os_jesd block.

If I remove also the ILA monitoring the output signals of the axi_adrv9009_rx_os_jesd block, the methodology critical warnings are only the last 9 of the previous cited.

Thank you

Maurizio

Thank you George,

but the example application where can be found?

Hi maurizio.sonzogni@abe.it ,

You should find the information here:

https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/adrv9009

For the no-os project, only one ORx channel can be active, so this initialization value should be changed:

https://github.com/analogdevicesinc/no-OS/blob/6b024163b1257dbd7c36a72bef693d4194cc1d5a/projects/adrv9009/profiles/tx_bw200_ir245p76_rx_bw200_or245p76_orx_bw200_or245p76_dc245p76/talise_config.c#L205

Regards,

George

Hi George,

I've changed the line setting the obsRxChannelsEnable value to TAL_ORX1 but the result is the same: DMA ok but values all equal to 0.

The no-OS with ADRV9008-2 (ZC706  + ADRV9008-2 W/PCBZ) is a supported and properly working (tested by developers) application both for HDL and no-OS?

Is the DMA Example the right example or the IIO Support?

The no-OS is a right way to proceed or must we take the Linux way?

Regards,

Maurizio

Hi maurizio.sonzogni@abe.it ,

The no-OS project was tested using an ADRV9009 board. I was also able to get DMA ORx data (non-zero values) with such a setup.

The right example would be IIO. Furthermore, I recommend testing the Tx output with a spectrum analyzer.

Making a Linux setup is straightforward. You should check your setup using the Linux image:

https://wiki.analog.com/resources/tools-software/linux-software/zynq_images/linux_hosts

https://wiki.analog.com/resources/tools-software/linux-software/kuiper-linux

Regards,

George

Hi George,

when using ADRV9009 in the DMA example the ORx are not expected.

Do you use a different headles.c file?

The output is correct as seen on a spectrum analyzer.

Thank you

Maurizio