IWRL6432AOP: Regarding the parameter c_DevClkCtrl of the rl_fecssDevClockCtrl API

Part Number: IWRL6432AOP
Other Parts Discussed in Thread: AWRL6432,

Tool/software:

The manual describes the value of the c_DevClkCtrl parameter in the rl_fecssDevClockCtrl API as follows:

The application can switch the clock source of FECSS based on power state to XTAL clock or Fast clock or can gate the FECSS system clock.
Recommended FECSS clock states:
XTAL Clock – Short idle time.
Fast Clock – Data acquisition mode, calibration or monitoring.
Clock Gate – Long frame idle time.

I have several questions regarding this description, as I would like to clarify the purpose and conditions for setting these values.

Q1) In normal radar control operation, is it correct to assume that selecting the Fast Clock is sufficient,
and that XTAL Clock and Clock Gate are options to consider when aiming to reduce power consumption during FECSS idle time?

Q2) I would like to clearly understand the conditions under which XTAL Clock and Clock Gate can be selected.
The mmwave_dfp_low_api_documentation describes typical use case programming sequences.
In these sequences, the rl_fecssDevClockCtrl API is executed in four states. In which of these states can XTAL Clock and Clock Gate be selected?

-Initialization state
-FECSS Power Down state
-De-Initialization State
-WarmBoot FECSS state


[Reference for programming sequence]
mmwave_dfp_low_api_documentation
{SDK_INSTALL_PATH}/firmware/mmwave_dfp/docs/mmwave_dfp_low_api_documentation/MMWAVE_LINK_DOC.html
Section: In-field Operation

Q3) Could you please explain the time constraints for "short idle time" and "long frame idle time"?
I would like to analyze under what conditions XTAL Clock and Clock Gate can be selected.

Q4) Are there any other prerequisites or limitations when selecting XTAL Clock or Clock Gate?

[Reference]
MMWAVE_L_SDK_05_05_03_00
mmwave_dfp_interface_control_document.pdf
Section 2.3.14 FECSS Device Clock Ctrl API

  • Hello, 

    I'm looking into your questions. Please give me a couple of days to get back to you with some answers.

    Best regards,

    Josh

  • Dear Dye,

    I would like to follow up and ask if there have been any developments regarding the investigation since our last communication.

  • Hi, Apologies for the delay in responding to your questions.

    1. Yes, Whenever Radar front end operations are performed like chirping, calibrations, monitoring etc. FECSS should run in fast clock mode.

    2. Init state: Fast Clock, for the rest of the states: it really depends on what application wants to do. For Example, 
    XTAL Clock - Short idle time.
    Clock Gate - Long frame idle time.

    3. Please refer to the TI mmWave SDK code for further details on how these are defined.

    4. No there are no limitations.

    Thanks,
    Kundan

  • Hi, thank you for the overview.
    I will consider Q1 closed.
    However, for accurate implementation, I would like to clarify a few additional points.

    Regarding Q2:
    In a separate thread, I was advised by a TI representative that the referenced documentation is general in nature, and that I should refer to the application note instead.
    Therefore, I would like to revisit Q2 based on section 6.2 "Software Sequence for Runtime (In-Field) Operation" of swra794b.pdf.
    Our application involves standard radar control, but we also aim to reduce power consumption whenever possible.
    For now, I would like to prioritize Q3 and revisit Q2 later.

    Regarding Q3:
    I checked the SDK, but there was no definition provided, and my original question remains unresolved.
    First, regarding "short idle time" — the meaning of this idle time is unclear.
    Is it correct to interpret this as a case where the frame idle time is short?
    Additionally, the expressions "short idle time" and "long frame idle time" are ambiguous.
    Could you please provide minimum and maximum time ranges for these definitions?
    For example:

    Short idle time: [min] > xxx msec / [max] < xxx msec
    Long frame idle time: [min] > xxx msec / [max] < xxx msec

  • Hi, 

    I am attaching an image below which talks about various states of AWRL6432 from front end application perspective.

    As you can see from the above image, the FECSS is Clock gated only during Inter frame idle times.
    You can refer to the xWRL6432 Power Consumption application note for more details on minimum inter frame idle times required to turn off the FECSS clock etc.

    Thanks,
    Kundan

  • Thank you for your message.
    Unfortunately, the upload seems to have failed, so I wasn't able to check the file on my end.
    Based on your reply, I assume you're referring to Figure 1-2. Typical Application Flow during 1 frame of operation in swra754.pdf, correct?
    If that's not the case, would it be possible for you to upload the correct file again?

    Also, just to confirm—swra754.pdf is the application note for IWRL6432AOP, is that correct?

    I’ve confirmed swra754.pdf, but unfortunately it didn’t resolve the original question I asked.
    Could you please take another look at Q3?

  • Hi, SWRA754 is the application note for Low power mode implementation in xWRLx432 platform of devices (xWRL1432, xWRL6432, xWRL6432AOP)

    The minimum idle times are already captured in the application note.

    Please go through the application note and it is clearly mentioned how the FECSS power domain is configured in different modes of operation.

    Thanks,
    Kundan

  • Thank you for the explanation.
    I understand that Interframe Idle can enter low power mode if the idle time is at least 135 µsec, which is helpful.
    However, this still doesn’t fully answer my original question Q3.
    The terms “short idle time” and “long frame idle time” remain ambiguous.
    Could you please provide clear time ranges (minimum and maximum) for these definitions?
    For example:

    • Short idle time: [min] > xxx µsec / [max] < xxx µsec
    • Long frame idle time: [min] > xxx µsec / [max] < xxx msec

    This clarification would help us better understand how to optimize power mode transitions.