Our application has a lower RX rate requirement than that for TX. We Monitor RX at a rate of 4 MSPS and when required to transmit, the rate is changed to accommodate TX requirement (4 MSPS to 60000 MSPS) as required. When required to cease transmission, the baseband rate is set to the minimum RX rate of 4 MSPS to save power. On a handful of occasions we have found that an ADRV9364 will not transmit IQ data until the system is rebooted. We have not attempted to cycle the AD9364 ensm_mode to any other states and then back to fdd to see if that resolves the issue largely because we are not able to duplicate it easily and we have no way of knowing when TX channel is non responsive. When TX channel is in this state, no matter what IQ data is sent to the TX channel, the output is a CW. We also see the following kernel messages:
[ 2652.175472] ad9361 spi3.0: Unhandled case in ad9361_tx_quad_calib line 2889 clkrf 3999999 clktf 15999999
[ 2652.213479] ad9361 spi3.0: Unhandled case in ad9361_tx_quad_calib line 2889 clkrf 3999999 clktf 15999999
[ 2652.937384] ad9361 spi3.0: Unhandled case in ad9361_tx_quad_calib line 2889 clkrf 3999999 clktf 15999999
[ 2712.005104] ad9361 spi3.0: Unhandled case in ad9361_tx_quad_calib line 2889 clkrf 3999999 clktf 15999999
[ 2712.042263] ad9361 spi3.0: Unhandled case in ad9361_tx_quad_calib line 2889 clkrf 3999999 clktf 15999999
[ 2712.813428] ad9361 spi3.0: Unhandled case in ad9361_tx_quad_calib line 2889 clkrf 3999999 clktf 15999999
We understand the message from looking at https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/ad9361.c#L2889 but have not idea how clkrf and clktf are selected such that the code ends up in a case that is not handled. And frankly, not sure that would necessarily cause the problem we are experiencing.
Next time the issues occurs, I'll try changing the rate and ensm mode. Any ideas to help us resolve this issue are welcome.
Fix language
[edited by: EdwardK at 5:30 PM (GMT -4) on 5 Oct 2022]
