AWR1243: Interpretation of AWR_AE_RF_INITCALIBSTATUS_SB asynchrounous event/message

Hi,

Could you confirm the firmware version and the sequence you are trying?

As I tried at my end using mmWave Studio on TIDEP-01012 (AWR1243 cascade) board. With and without calling RfInitCalibConfig with value 0x1FF0 I get the same set of status and update value in the RF_init async-event (SB-ID 0x1004)  [ 0x8000_2FFE (status), 0x8000_3FFC (update)] from Master and Slave chip.

Regards,

Jitendra

Hi,

Thanks for your fast reply. We are flashing the metaimage in mmwave_dfp_01_02_00_01.

By sequence, I guess you mean how we setup the master and slave? 

We start by a power-on sequence so it contains the calls to API methods rlDevicePowerOn, rlDeviceRfStart and rlSetChannelConfig (which actually sets Master and Slave).

We continue with a basic configuration (ADC output, data path, LVDS lines, etc.) including the call to rlRfInitCalibConfig followed by rlRfInit (with a sleep in between of few hundreds of ms).

Finally, we perform the profile configuration (rlSetProfileConfig).

Please let us know if this is in alignment with radar protocol.

Best regards,

M.

Could you check the firmware version to be matching with flashed binary using rlDeviceGetVersion API?

And do you see same observation without calling rlRfInitCalibConfig API?

Regards,

Jitendra

Hi Jitendra

If we are doing it correctly, both Master and Slave return the following rlVersion_t fields:

rf.fwMajor 2

rf.fwMinor 0

rf.fwBuild 0

rf.fwDebug 1

master.fwMajor 1

master.fwMinor 10

master.fwBuild 0

master.fwDebug 20

mmWaveLink.major 1

mmWaveLink.minor 2

mmWaveLink.build 0

mmWaveLink.debug 0

rf.patchMajor 1

rf.patchMinor 2

rf.patchBuildDebug 03

master.patchMajor 1

master.patchMinor 2

master.patchBuildDebug 02

In any case, is the original issue (rlRfInitCalibConfig showing wrong status and update fields in cascaded config) a known issue for such FW version? 

Thanks

M.

I include also a test where we call and do not call rlRfInitCalibConfig:

Slave seems to behave consistently.

Could the change in STATUS field between both experiments and Master chips be to external factors e.g., temperature?

What about the difference between STATUS to UPDATE?

Best regards,

M.

Hi,

Did you disable Tx for slaves? What is channelConfig setting for the slaves? If Tx channels are disabled then Tx-power, Tx Phase and IQMM calibration will be failed.

And for rfRfInitCalibConfig you need to 0x1FF0 to enable all the calibration, other bits are reserved. In your case you haven't set the b'12.

Status: is current calibration execution status (1:pass, 0:fail)

Update: will be set to '1' if it gets new calibration update/value for specific calibration type which is different compare to old calibration status.

For Master main issue what  I see is SYNTH-VCO1 and VCO2 calibration status. Could you confirm if you are interpreting the received SPI data correctly here?

You are using old firmware/DFP version, the latest version for AWR1243/P is v1.2.5.1. I would request you to migrate to this version.

Regards,

Jitendra

Hi Jitendra,

Thanks for your feedback.

Did you disable Tx for slaves? => Yes, txChannelEn is set to 0 for the slave. We employ Master's 1 TX channel.

What is channelConfig setting for the slaves?  => cascading is set to 2 for the slave. Could you please specify which pinout to use for both Master and Slave? We're using a looped-back LO in the actual HW.

If Tx channels are disabled then Tx-power, Tx Phase and IQMM calibration will be failed. => Understood.

And for rfRfInitCalibConfig you need to 0x1FF0 to enable all the calibration, other bits are reserved. In your case you haven't set the b'12. => Understood. Here you have the results I get now in the async message using that mask:

Now results are consistent between calling and not calling rlRfInitCalibConfig, so thanks for the hint.

Could you confirm if you are interpreting the received SPI data correctly here? => We believe so since otherwise we will probably have not been able to follow a successful config procedure. However we will double check.

You are using old firmware/DFP version, the latest version for AWR1243/P is v1.2.5.1. I would request you to migrate to this version => Understood.

Finally, which API method can be used to prevent any update of the calibration registers between boot-ups and use a default set of them everytime?

Thanks for your support.

Best regards,

M.

Hi,

I get the same value as your table at my end.

user6150371 said:

which API method can be used to prevent any update of the calibration registers between boot-ups and use a default set of them everytime?

If you do not want to disable/enable a specific set of boot time calibration then you don't need to invoke rlRfInitCalibConfig but directly use rf_init.

Regards,

Jitendra

Hi Jitendra,

Great! What about the pinout config field used?

And regarding the calibration, it's clear that we can control which calibrations enable/disable at boot up. What about storing exactly the same one and load it upon RfInit ?

Thanks

M.