AnsweredAssumed Answered

AD9364 failing dig_tune BIST

Question asked by HStoner on Feb 29, 2016
Latest reply on Mar 4, 2016 by DragosB

We have a custom board implementation with an AD9364 device interfaced via LVDS to the ADI axi_adc and axi_dds fpga cores, within an Altera Cyclone V SoC.   We are running linux on the ARM processor on the SoC, and are using the 2015_R1 versions of the fpga cores and the axi-ad9361 drivers.

 

The problem I'm having is that on our Custom board, the dig_tune BIST test is failing, and I don't really have any good idea as to why.  I'm hoping the information below will provide some clue, or someone can tell us what to look for to find the root cause of this failure.

 

We're also able to run the same linux kernel and drivers on and SoCKit + ARRadio evaluation board.  The device tree file is modified on our custom board for only a couple of properties, compared with the SoCKit/ARRadio  device tree:

- we are using a 50 MHz external reference instead of the 40 MHz xtal reference that the eval board is running;

     -  set clock-frequency = <50000000> in ad9361_clkin: clock@0

- we have turned off the adi, 2rx-2tx-mode-enable property, since there is only one rx/tx channel for the AD9364.

 

- I have currently set the ad9361 and cf_axi_adc drivers to be loaded manually as modules...  I've also tried going back to having them built-in to the kernel, but it doesn't make any difference with getting through the dig_tune BIST test...

 

On our eval board, the ad9361 and cf_axi_adc drivers load fine, and complete all BIST tests successfully.

But on our custom board, dig_tune() is failing when the cf_axi_driver probes, with the following verbose output...

axiadc_channel_setup : entered... adc_chan_num = 2

SAMPL CLK: 25000000 tuning: RX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

 

SAMPL CLK: 40000000 tuning: RX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

 

SAMPL CLK: 61440000 tuning: RX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

 

SAMPL CLK: 61440000 tuning: RX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

 

ad9361 spi0.0: ad9361_dig_tune: Tuning RX FAILED!

SAMPL CLK: 25000000 tuning: TX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

1:2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

 

SAMPL CLK: 40000000 tuning: TX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

1:2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

 

SAMPL CLK: 61440000 tuning: TX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

1:2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

 

SAMPL CLK: 61440000 tuning: TX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

1:2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

 

ad9361 spi0.0: ad9361_dig_tune: Tuning TX FAILED!

 

On the SoCKit + ARRadio Eval Board, running the same driver loading/ initialization, I receive the following output and successful driver loads...

axiadc_channel_setup : entered... adc_chan_num = 4

SAMPL CLK: 25000000 tuning: RX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:0 0 0 4 4 4 2 2 6 4 0 0 0 0 0 0

1:0 0 0 0 0 0 0 0 0 0 0 0 0 6 2 2

 

SAMPL CLK: 40000000 tuning: RX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:4 4 2 6 6 4 2 2 6 4 6 0 0 0 4 6

1:4 0 0 0 0 0 0 0 0 4 2 2 6 6 6 2

 

SAMPL CLK: 61440000 tuning: RX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:6 6 2 6 6 4 6 6 6 6 6 6 4 0 4 6

1:6 4 4 0 0 0 6 2 2 6 6 6 6 6 6 6

 

SAMPL CLK: 61440000 tuning: RX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:6 6 2 6 6 4 6 6 6 6 6 6 4 0 4 6

1:6 4 4 0 0 0 6 2 2 6 6 6 6 6 6 6

 

SAMPL CLK: 25000000 tuning: TX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:2 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0

1:2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

 

SAMPL CLK: 40000000 tuning: TX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:2 4 0 0 0 0 0 0 0 0 0 0 4 6 2 2

1:2 2 2 2 2 2 2 2 2 2 2 2 2 2 6 6

 

SAMPL CLK: 61440000 tuning: TX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:2 4 0 0 0 0 0 4 2 2 2 2 6 6 2 2

1:2 2 2 2 2 2 2 2 2 6 6 2 2 2 6 6

 

SAMPL CLK: 61440000 tuning: TX

  0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:

0:2 4 0 0 0 0 0 4 2 2 2 2 6 6 2 2

1:2 2 2 2 2 2 2 2 2 6 6 2 2 2 6 6

 

cf_axi_adc ff220000.cf-ad9361-lpc: ADI AIM (8.00.a) at 0xFF220000 mapped to 0xc0a40000, probed ADC AD9361 as MASTER

 

Note that I have replaced the printing of '#' in ad9361_dig_tune_verbose_print() with printing of the actual value that is stored in the 'field[][]' array here, so I could see what values were being written there. 

 

 

I also added some additional debugging in the function 'axiadc_probe()', where the HDL core registers are reset...

After resetting the ADC Common Cores, by writing 0, then 0x3 to ADI_REG_RSTN (register 0x40), I print out some of the ADC Common and Channel Core Register contents...

First, from our failing custom board...

axiadc_probe: checking ADC common core registers...                                   

... REG_VERSION(0x0) = 0x90062                                                    

... REG_RSTN(0x40) = 0x3                                                          

... REG_CNTRL(0x44) = 0x0                                                         

... REG_CLK_FREQ(0x54) = 0x9d17                                                    

... REG_CLK_RATIO(0x58) = 0x1                                                     

... REG_STATUS(0x5c) = 0x4                           // NOTE: lsbit (STATUS) is clear, indicating Interface Error?

... REG_DELAY_CNTRL(0x60) = 0x0                                                  

... REG_DELAY_STATUS(0x64) = 0x0                                                     

... REG_DRP_CNTRL(0x70) = 0x0                                                 

... REG_DRP_STATUS(0x74) = 0x20000                                                                                    

... REG_DMA_STATUS(0x88) = 0x2                                       

... REG_USR_CNTRL_1(0xa0) = 0x3                                    

... REG_ADC_DP_DISABLE(0xc0) = 0x0                                                               

axiadc_probe: checking ADC channel core registers...                                              

... channel 0 ...                                                            

... REG_CHAN_CNTRL(0x400) = 0x0                                                        

... REG_CHAN_STATUS(0x404) = 0x2                                                   

... REG_CHAN_CNTRL_1(0x410) = 0x0                                                          

... REG_CHAN_CNTRL_2(0x414) = 0x0                                                

... REG_CHAN_CNTRL_3(0x418) = 0x0                                                      

... REG_CHAN_USR_CNTRL_1(0x420) = 0x1001010                                          

... REG_CHAN_USR_CNTRL_2(0x424) = 0x10001                                         

... channel 1 ...                                                                    

... REG_CHAN_CNTRL(0x440) = 0x0                                                                  

... REG_CHAN_STATUS(0x444) = 0x2                                                 

... REG_CHAN_CNTRL_1(0x450) = 0x0                                                            

... REG_CHAN_CNTRL_2(0x454) = 0x0

... REG_CHAN_CNTRL_3(0x458) = 0x0                                                 

... REG_CHAN_USR_CNTRL_1(0x460) = 0x1001010                                       

... REG_CHAN_USR_CNTRL_2(0x464) = 0x10001                                         

axiadc_probe: checking DAC common core registers...                                 

... REG_VERSION(0x4000) = 0x80062                                                 

... REG_RSTN(0x4040) = 0x3                                                                            

... REG_RSTN(0x4040) = 0x3                                                       

... REG_CNTRL_1(0x4044) = 0x0                                                        

... REG_CNTRL_2(0x4048) = 0x0                                                 

... REG_RATECNTRL(0x404c) = 0x0                                                                                       

... REG_FRAME(0x4050) = 0x0                                          

... REG_CLK_FREQ(0x4054) = 0x9d15                                  

... REG_CLK_RATIO(0x4058) = 0x1                                                                  

... REG_STATUS(0x405c) = 0x1                                                                     

... REG_DRP_CNTRL(0x4070) = 0x0                                               

... REG_DRP_STATUS(0x4074) = 0x20000                                                   

... REG_DMA_STATUS(0x4088) = 0x3                                                   

... REG_USR_CNTRL_1(0x40a0) = 0x3                                                          

... REG_DAC_DP_DISABLE(0x40c0) = 0x0


Note that Register 0x5c (REG_STATUS), immediately after resetting the cores and reading this register, indicates an Error (STATUS bit is 0).  I noted this, because later, when the dig_tune test is run, it appears to be the ADI_STATUS bit that is checked after the tuning test, and if clear this tells the driver to set the field[][] value to '1' for that RX_DATA_DELAY, DATA_CLK_DELAY combination.  I would expect that this bit should be set, indicating no Interface error, immediately after the Cores are Reset ????


Here is the same output when using the SoCKit + ARRadio Eval board, immediately after resetting the Cores in the axiadc_probe() function...

axiadc_probe: checking ADC common core registers...

... REG_VERSION(0x0) = 0x80061

... REG_RSTN(0x40) = 0x3

... REG_CNTRL(0x44) = 0x0

... REG_CLK_FREQ(0x54) = 0x13a92

... REG_CLK_RATIO(0x58) = 0x1

... REG_STATUS(0x5c) = 0x5                         // NOTE: lsbit (STATUS) is set here, indicating no Error?

... REG_DELAY_CNTRL(0x60) = 0x0

... REG_DELAY_STATUS(0x64) = 0x200

... REG_DRP_CNTRL(0x70) = 0x0

... REG_DRP_STATUS(0x74) = 0x20000

... REG_DMA_STATUS(0x88) = 0x0

... REG_USR_CNTRL_1(0xa0) = 0x3

... REG_ADC_DP_DISABLE(0xc0) = 0x0

axiadc_probe: checking ADC channel core registers...

... channel 0 ...

... REG_CHAN_CNTRL(0x400) = 0x0

... REG_CHAN_STATUS(0x404) = 0x2

... REG_CHAN_CNTRL_1(0x410) = 0x0

... REG_CHAN_CNTRL_2(0x414) = 0x0

... REG_CHAN_CNTRL_3(0x418) = 0x0

... REG_CHAN_USR_CNTRL_1(0x420) = 0x1001010

... REG_CHAN_USR_CNTRL_2(0x424) = 0x10001

... channel 1 ...

... REG_CHAN_CNTRL(0x440) = 0x0

... REG_CHAN_STATUS(0x444) = 0x2

... REG_CHAN_CNTRL_1(0x450) = 0x0

... REG_CHAN_CNTRL_2(0x454) = 0x0

... REG_CHAN_CNTRL_3(0x458) = 0x0

... REG_CHAN_USR_CNTRL_1(0x460) = 0x1001010

... REG_CHAN_USR_CNTRL_2(0x464) = 0x10001

axiadc_probe: checking DAC common core registers...

... REG_VERSION(0x4000) = 0x80061

... REG_RSTN(0x4040) = 0x3

... REG_RSTN(0x4040) = 0x3

... REG_CNTRL_1(0x4044) = 0x0

... REG_CNTRL_2(0x4048) = 0x0

... REG_RATECNTRL(0x404c) = 0x0

... REG_FRAME(0x4050) = 0x0

... REG_CLK_FREQ(0x4054) = 0x13a92

... REG_CLK_RATIO(0x4058) = 0x1

... REG_STATUS(0x405c) = 0x1

... REG_DRP_CNTRL(0x4070) = 0x0

... REG_DRP_STATUS(0x4074) = 0x20000

... REG_DMA_STATUS(0x4088) = 0x1

... REG_USR_CNTRL_1(0x40a0) = 0x3

... REG_DAC_DP_DISABLE(0x40c0) = 0x0



We've done some probing of the RX_D0-D5 data lines, and the DATA_CLK and RX_FRAME signals on our board, and it looks like there are potentially valid signals there.   We're not sure where to look to isolate this failure.  Please let me know if there is more information that I can provide to help diagnose this.



Outcomes