Profile load causes unexpected MCS sync status (0x0) on fmcomms8 following MCS.sh script

Hi, 

I'm using the build from this post, i.e. master HDL and  fmcomms8_zu11eg_master linux branches, also now on the fmcomms8 wiki, with a ZU11EG SOM + DB setup.

https://ez.analog.com/fpga/f/q-a/164450/fmcomms8-chips-c-and-d-relative-phase-changes-when-mcs-sync-is-reissued 

The build comes with a script that fixes MCS sync for all 8 channels (MCS.sh). While this works, there seems to be an issue with profile loading. Profiles may be loaded as normal prior to running the MCS.sh script, but after running it, any profile that is loaded seems to fail with the attached error. 

adrv90009 spi1.1: adrv9009_do_setup:675 Unexpected MCS sync status (0x0)

Every profile I've tried fails, but for the attached dmesg log I used the `Tx_BW200_IR245p76_Rx_BW200_OR245p76_ORx_BW200_OR245p76_DC245p76.txt` example profile that ships with the iio-oscilloscope. 

A temporary work-around is to ensure the desired profile is loaded before MCS sync is run, and never attempt to load again, but I just wanted to post to make sure you were aware of the issue.

If there is an easy fix that allows profile loading to happen again as normal, would appreciate that, but if not and it is a work in progress, we can use the work-around until the next formal release. 

Thanks,
Adam 


Tx_BW200_IR245p76_Rx_BW200_OR245p76_ORx_BW200_OR245p76_DC245p76.txt
<profile Talise version=1 name=Tx_BW200_IR245p76_Rx_BW200_OR245p76_ORx_BW200_OR245p76_DC245p76>
 <clocks>
  <deviceClock_kHz=245760>
  <clkPllVcoFreq_kHz=9830400>
  <clkPllHsDiv=2.5>
 </clocks>

 <rx name=Rx 200.00MHz, OutputRate 245.76MHz, TotalDecimation 8>
  <rxFirDecimation=2>
  <rxDec5Decimation=4>
  <rhb1Decimation=1>
  <rxOutputRate_kHz=245760>
  <rfBandwidth_Hz=200000000>
  <rxBbf3dBCorner_kHz=200000>
  <rxDdcMode=0>

  <rxNcoShifterCfg>
   <bandAInputBandWidth_kHz=0>
   <bandAInputCenterFreq_kHz=0>
   <bandANco1Freq_kHz=0>
   <bandANco2Freq_kHz=0>
   <bandBInputBandWidth_kHz=0>
   <bandBInputCenterFreq_kHz=0>
   <bandBNco1Freq_kHz=0>
   <bandBNco2Freq_kHz=0>
  </rxNcoShifterCfg>

  <filter FIR gain_dB=-6 numFirCoefs=48>
  -7
  -23
  33
  50
  -70
  -110
  144
  205
  -259
  -356
  437
  581
  -698
  -916
  1082
  1415
  -1655
  -2209
  2567
  3615
  -4351
  -7169
  9329
  31129
  31129
  9329
  -7169
  -4351
  3615
  2567
  -2209
  -1655
  1415
  1082
  -916
  -698
  581
  437
  -356
  -259
  205
  144
  -110
  -70
  50
  33
  -23
  -7
  </filter>

  <rxAdcProfile num=42>
  185
  141
  172
  90
  1280
  942
  1332
  90
  1368
  46
  1016
  19
  48
  48
  37
  208
  0
  0
  0
  0
  52
  0
  7
  6
  42
  0
  7
  6
  42
  0
  25
  27
  0
  0
  25
  27
  0
  0
  165
  44
  31
  905
  </rxAdcProfile>
 </rx>

 <obsRx name=Rx 200.00MHz, OutputRate 245.76MHz, TotalDecimation 8>
  <enAdcStitching=0>
  <rxFirDecimation=2>
  <rxDec5Decimation=4>
  <rhb1Decimation=1>
  <orxOutputRate_kHz=245760>
  <rfBandwidth_Hz=200000000>
  <rxBbf3dBCorner_kHz=225000>
  <orxDdcMode=0>

  <filter FIR gain_dB=-6 numFirCoefs=48>
  -7
  -21
  31
  48
  -67
  -106
  124
  164
  -275
  -334
  440
  552
  -694
  -872
  1069
  1351
  -1633
  -2111
  2541
  3477
  -4295
  -6877
  9433
  30825
  30825
  9433
  -6877
  -4295
  3477
  2541
  -2111
  -1633
  1351
  1069
  -872
  -694
  552
  440
  -334
  -275
  164
  124
  -106
  -67
  48
  31
  -21
  -7
  </filter>

  <orxLowPassAdcProfile num=42>
  185
  141
  172
  90
  1280
  942
  1332
  90
  1368
  46
  1016
  19
  48
  48
  37
  208
  0
  0
  0
  0
  52
  0
  7
  6
  42
  0
  7
  6
  42
  0
  25
  27
  0
  0
  25
  27
  0
  0
  165
  44
  31
  905
  </orxLowPassAdcProfile>

  <orxBandPassAdcProfile num=42>
  185
  141
  172
  90
  1280
  942
  1332
  90
  1368
  46
  1016
  19
  48
  48
  37
  208
  0
  0
  0
  0
  52
  0
  7
  6
  42
  0
  7
  6
  42
  0
  25
  27
  0
  0
  25
  27
  0
  0
  165
  44
  31
  905
  </orxBandPassAdcProfile>

 </obsRx>

 <lpbk>
  <rxFirDecimation=2>
  <rhb1Decimation=1>
  <outputRate_kHz=245760>
  <rfBandwidth_Hz=75000000>
  <rxBbf3dBCorner_kHz=225000>

  <filter FIR gain_dB=-6 num=48>
  -7
  -21
  31
  48
  -67
  -106
  124
  164
  -275
  -334
  440
  552
  -694
  -872
  1069
  1351
  -1633
  -2111
  2541
  3477
  -4295
  -6877
  9433
  30825
  30825
  9433
  -6877
  -4295
  3477
  2541
  -2111
  -1633
  1351
  1069
  -872
  -694
  552
  440
  -334
  -275
  164
  124
  -106
  -67
  48
  31
  -21
  -7
  </filter>

  <lpbkAdcProfile num=42>
  243
  143
  181
  90
  1280
  485
  1275
  37
  1317
  23
  797
  35
  48
  48
  30
  174
  0
  0
  0
  0
  44
  0
  7
  6
  42
  0
  7
  6
  42
  0
  25
  27
  0
  0
  25
  27
  0
  0
  165
  44
  31
  905
  </lpbkAdcProfile>
 </lpbk>

 <tx name=Tx 200.00MHz, InputRate 245.76MHz, TotalInterpolation 8>
  <dacDiv=1>
  <txFirInterpolation=1>
  <thb1Interpolation=2>
  <thb2Interpolation=2>
  <thb3Interpolation=2>
  <txInt5Interpolation=1>
  <txInputRate_kHz=245760>
  <primarySigBandwidth_Hz=75000000>
  <rfBandwidth_Hz=200000000>
  <txDac3dBCorner_kHz=200000>
  <txBbf3dBCorner_kHz=100000>

  <filter FIR gain_dB=0 numFirCoefs=20>
  33
  -77
  123
  -158
  171
  -112
  -155
  1040
  -3011
  20121
  -3011
  1040
  -155
  -112
  171
  -158
  123
  -77
  33
  0
  </filter>
 </tx>
</profile>

  • Digging a bit deeper into this issue, the line that fails happens during MCS sync, so this is not necessarily a profile loading issue, but rather a consequence of the fact that MCS sync happens as part of the adrv9009_do_setup() function from fmcomms8_zu11eg_master/drivers/iio/adc/adrv9009.c 


    The failure on line 675 is when MCS status is queried. Comparing to line 1180, this corresponds to step (3) in the MCS sync process. Previously, step 2 of MCS sync in the old way would hold a GPIO high for 1ms and then lower it to trigger pulses from the HMC7044, as in the function adrv9009_sysref_req(). 

    In fixing the phase sync issue, the MCS.sh script alters register 0x05A on the HMC7044 to move from level sensitive mode to a fixed number of pulses, and sends the sysref request separately over SPI to the carrier HMC7044. 

    With the driver still using the old level sensitive method, step (2) fails, pulses never arrive, and then step (3) of MCS declares bad MCS status.

    ---------------------------------------------------------------

    Long story short, there are probably multiple potential ways to resolve this issue

    1) Reconfigure the HMC7044s back to level sensitive mode prior to loading a profile as they are so that when the driver executes adrv9009_do_setup() and hits steps 2 of the MCS sync process, pulses are triggered.

    2) Comment out the MCS sync steps from adrv9009_do_setup() to allow profile loading to finish, then later re-issue the new procedure from MCS.sh later to all chips.

    3) Update the driver code to perform the new MCS.sh procedure, rather than the old style level-sensitive.

    (1) is easiest, (2) is next easiest but could have issues with the radios not setting up correctly. (3) is more something that will likely be done in a formal release later this year anyway, and somewhat ties into understanding what kind of clock tree configuration is in place (single ADRV9009 vs. fmcomms8 vs multi som etc.).

    ------------------------------------------------------------------

    We went with (1), and it worked. Essentially, before loading a profile, execute

    # return to level sensitive since adrv9009_do_setup() 
    # does a partial MCS sync using gpio levels
    iio_reg hmc7044 0x5a 0x0
    iio_reg hmc7044-fmc 0x5a 0x0
    

    after which a new MCS sync using MCS.sh can be re-issued. 


    Thanks,
    Adam