This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AWR2944EVM: RF terminal control

Part Number: AWR2944EVM
Other Parts Discussed in Thread: AWR2944

Commissioning device: AWR2944 EVM

Debug environment: CCS 12.5.0

Use demos: awr2944_mmw_nonos_demo_dssTDM and awr2944_mmw_nonos_demo_mssTDM

Description of the problem: When the MSS sends a radar message to the RF end, the MSS sends an MSGID of the same type, and the RF end replies with the same MSGID. When I follow the figure 4 on page 11 of document C:\ti\mmwave_mcuplus_sdk_04_04_01_02\mmwave_dfp_02_04_09_01\docs\mmwave_dfp_user_guide.pdf, the MSS end controls the RF end, When the MSS command is sent to rlRfInit and the MSS has received the reply message from the RF, under what conditions will the RF send the RL_RF_AE_INITCALIBSTATUS message?

  • Hi Simon,

    As soon as the MSS sends the rlRfInit message to the BSS(RF Front-End), it is acknowledged immediately from BSS side. Now, upon receiving rlRfInit message BSS performs the boot time calibrations(e.g. - Tx power, Rx gain, LODIST calibration, etc). And as a response of boot time calibration, the BSS sends an async event with the calibration status. MSS cannot issue any other API until this async event is received. Basically RL_RF_AE_INITCALIBSTATUS event signifies that the RF initialization is done properly.

    This boot time calibration happens by default so, under any condition the RF must send RL_RF_AE_INITCALIBSTATUS async event after the rlRfInit acknowledgement. Host(here MSS) can disable any of the calibration with RF_INIT_CALIB_ENABLE_MASK in AWR_RF_INIT_CALIBRATION_CONF_SB API. But in that case host needs to inject calibration data for that specific calibrations.

    Please go through below APIs from Radar Interface Control Document - 

    1) AWR_RF_INIT_CALIBRATION_CONF_SB

    2) AWR_RF_INIT_SB

    3) AWR_AE_RF_INITCALIBSTATUS_SB

    Regards,
    Anirban

  • Thank you for your reply!
    My understanding is: suppose I still use all calibration modules with RF_INIT_CALIB_ENABLE_MASK in the AWR_RF_INIT_CALIBRATION_CONF_SB API. After I send the command AWR_RF_INIT_SB to RF through MSS, RF replies to the AWR_AE_RF_INITCALIBSTATUS_SB message. During this period, RF does two things: 1. Reply to a message from the MSS. AWR_RF_INIT_SB; 2. If the startup time is being calibrated, RF does not send WR_AE_RF_INITCALIBSTATUS_SB message if only one item of information is incorrect. Is my understanding correct?
    If understood correctly, what causes RF calibration failure?
  • Hi Simon,

    After receiving RF_INIT message BSS immediately sends an acknowledgement that the message is received. After the front-end initialization is done, BSS performs the boot time calibrations and sends out the reports as AWR_AE_RF_INITCALIBSTATUS_SB async event message. So, yes BSS is doing two things - (i) Sends ack to MSS  and  (ii) Perform calibrations and sends out reports

    MSS cannot issue any other APIs during this time(i.e. from sending RF_INIT to receiving calibration status reports).

    2. If the startup time is being calibrated, RF does not send WR_AE_RF_INITCALIBSTATUS_SB message if only one item of information is incorrect.

    Here I'm a bit unclear about your 2nd point, can you please elaborate it clearly?

    Regards,
    Anirban 

  • Thank you for your reply!
    The second point of question is where you say "Host(here MSS) can disable any of the calibration with RF_INIT_CALIB_ENABLE_MASK in AWR_RF_INIT_CALIBRATION_CONF_SB API. But in that case host needs to inject calibration data for that specific calibrations." When I am selecting all calibration options that enable RF_INIT_CALIB_ENABLE_MASK, will RF not send the RL_RF_AE_INITCALIBSTATUS event if a calibration error occurs during my startup time calibration?

    What I want to confirm is whether the RL_RF_AE_INITCALIBSTATUS event will not be sent because of the RF calibration error?

  • Hi Simon,

    Yes, the BSS will always sends this calibration reports irrespective of the calibration status. At application side when AWR_AE_RF_INITCALIBSTATUS_SB async event is received the end user needs to implement the status check for each of the enabled calibrations. If error occurs during any of the enabled calibrations, then the corresponding bit in CALIBRATION_STATUS will be zero.

    Status bit for each calibration:    0 - Fail    1 - Pass

    I'd highly appreciate if you can go through the AWR_AE_RF_INITCALIBSTATUS_SB response content from Radar ICD document(page 264)[Found at - mmwave_mcuplus_sdk_04_04_01_02/mmwave_dfp_02_04_09_01/docs/mmWave-Radar-Interface-Control.pdf]

    Regards,
    Anirban

  • Thank you for your reply. I understand what you mean.
    However, when I used the above project to debug, after I sent AWR_RF_INIT_SB to RF using MSS, although RF responded, RF did not send the AWR_AE_RF_INITCALIBSTATUS_SB command. What is the cause of this problem?

  • Hi Simon,

    I just confirmed with my team that the Non-OS TDM OOB Demo doesn't work properly. It is not due to the AWR_AE_RF_INITCALIBSTATUS_SB reports, but seems to be a bug in the demo. I have already raised an issue on this, and will be fixed on the upcoming version.

    For now you can use the Non-OS DDM OOB Demo, that runs perfectly fine.

    Regards,
    Anirban

  • Thank you for your reply!
    Is it convenient for you to tell me the problem of TDMA without an operating system? If it is not convenient, when can you provide the repaired version?

    As for this version of TDMA without operating system, I have also done the following tests:
    1. Question 1: Only one command can be read from the CLI. Otherwise, the command is invalid.
    2. Question 2: After all the commands are sent, the DPC_ObjectDetection_frameStart function is successfully started and can be executed. After comparing DDMA program, it is found that the DPC_Objdet_Assert function in the function is noted out, and the data processing process can continue to advance. However, there is no view option in the mmWave Demo Visualizer's plot interface.
    Please continue to track and solve the above problems, thank you

  • Hi Simon,

    I am not aware of the exact bug/problem lies in the demo. I have already raised this issue for fixing. 

    I'd recommend not to waste your time on this demo as it is a known bug. The next release is yet to be decided.

    Regards,
    Anirban