AWR2944: How to enable frame_start, chirp_start and chirp_end pulses?

Hi Mark,

We will check on this with our team internally and get back to you in a couple of days with an update on this.

Thanks,

Pradipta.

Hi,

Is there any update on support for this?

I have since tried something which gives some kind of success but not completely what I want and not knowing if it's the correct way to do it.

As I mentioned in my original post, adding the pins does not generate any changes to the source code files in SysConfig, However, if I open SysConfig and create a new design for a AWR294X (without selecting an SDK), I can see that code is generated in the AWR294X_pinmux_data.c file.

For example, the following code is generated when I add the FRAME_START signal

#include "AWR294X_pinmux.h"

/** Peripheral Pin Configurations */


static pinmuxPerCfg_t gMyframe_start0PinCfg[] =
{
    /* MyFRAME_START1 -> FRAME_START -> R15 */
    {
        CSL_MSS_IOMUX_PADAY_CFG_REG, PIN_MODE(7) | \
        ((PIN_PULL_DISABLE) & (~PIN_PULL_DIRECTION))
    },
    {PINMUX_END}
};
static pinmuxModuleCfg_t gFrame_startPinCfg[] =
{
    { 0, TRUE, gMyframe_start0PinCfg},
    {PINMUX_END}
};
       

pinmuxBoardCfg_t gAWR294XPinmuxData[] =
{
    {0, gFrame_startPinCfg},
    {PINMUX_END}
};

Taking this as a base I tried two methods of adding this manually to the ti_pinmux_config.c (in mssgenerated).

1. I took only the first part of the code generated and replaced the definition for the pin, adding the following:

{
    PIN_PAD_AY, PIN_MODE(7) | \
    ((PIN_PULL_DISABLE) & (~PIN_PULL_DIRECTION))
},

2. I used what was previously in the ti_pinmux_config.c as a base and added the pins as follows:

{
    PIN_PAD_AY,
    ( PIN_MODE(7) )
},

Results:

1. CHIRP_END and CHIRP_START signals appear to be generated but I cannot measure or detect FRAME_START pulses.

2. The same results as 1 - CHIRP_END and CHIRP_START pulses appear to be generated but not for FRAME_START.

Questions:

1. Is this a correct configuration or am I missing something?

2. When I measure CHIRP_START with an oscilloscope, the pulse appears to be only a few nanoseconds. I'm not sure if this is a limitation of my scope or if this is expected. How long are generated pulses for these signals meant to be?

3. Is there any reason why CHIRP_START and CHIRP_END appear to somewhat work but FRAME_START does not?

Thanks,

Mark

In addition to looking for confirmation on the above being the correct method, can you please help explain the following:

Why am I seeing 16 additional pulses on the FRAME_START line for a single frame when I should be seeing one? See image below of FRAME_START line when loading a profile configuration to capture a single frame using LVDS and DCA1000EVM.

Context for above image: this is a custom profile but for a modified version of the profile_LVDS.cfg where number of frames is set to 1 instead of 20, I see similar behavior - rather than 16 additional pulses I measure 12. Important to note, these measurements and results are repeatable.

The additional pulses can also be measured on the CHIRP_END line. Additional pulses at the beginning when the profile is loaded before the correct number of CHIRP_END pulses.

Also, to be clear, I have mux'd the FRAME_START line to PIN_PAD_AZ (G15) and the signal works on this line. However, it still does not work on PIN_PAD_AY (R15) and I have no explanation for this - if I'm missing some knowledge on why this is not working it would be greatly appreciated.

Thanks,

Mark

Hi Mark,

I am checking on this with all the details shared by you. I will need some time to come up with an update for this. Will try to reply by the end of the week. 

Thanks,

Pradipta.

Hi Mark,

Please find my comments below for the pending queries.

1. Is this a correct configuration or am I missing something?

Comment) The correct method to configure this has been explained above. Let me know if you have any queries on it. 

2. When I measure CHIRP_START with an oscilloscope, the pulse appears to be only a few nanoseconds. I'm not sure if this is a limitation of my scope or if this is expected. How long are generated pulses for these signals meant to be?

Comment) It is expected behavior. The pulse width will be 5nanoseconds.

3. Is there any reason why CHIRP_START and CHIRP_END appear to somewhat work but FRAME_START does not?

Comment) Please check if the configuration is done correctly or not. 

4. Why am I seeing 16 additional pulses on the FRAME_START line for a single frame when I should be seeing one? See image below of FRAME_START line when loading a profile configuration to capture a single frame using LVDS and DCA1000EVM.

Comment) The device performs the boot time calibrations. In my understanding they are due to calibrations. Can you disable the run time and boot time calibrations and let us know if your observations change or remain the same. 

5. Also, to be clear, I have mux'd the FRAME_START line to PIN_PAD_AZ (G15) and the signal works on this line. However, it still does not work on PIN_PAD_AY (R15) and I have no explanation for this - if I'm missing some knowledge on why this is not working it would be greatly appreciated.

Comment) We will need to check this on the bench to confirm this behavior. As per my understanding if the pin is properly configured it should work. 

Thanks,

Pradipta.

Hi Pradipta,

Thank you for the response, I have been testing out the proposed solutions on my hardware.

1. The pinmux configuration is working to enable the pulses on FRAME_START, CHIRP_START and CHIRP_END. FRAME_START does appear to, sort of, work on pin R15. However, I measure a very small voltage on this pin in comparison to G15. Under 400mV measured vs approx. 1.7v on G15.
2. I have disabled calibrations in the source code, in mss_main.c

   calibrationCfg.u.chirpCalibrationCfg.enableCalibration    = false;

   This appears to solve the additional pulses on FRAME_START line
3. Point 2 above solves the additional pulses on FRAME_START from the 2nd load of a profile config on. However, I am getting a lot of additional pulses when I load for the first time a profile configuration after a reboot or reset of the AWR2944. Approx. 300+ pulses counted. If calibration is disabled in source code what could be causing these pulses?
4. I tried modifying calibData in the profile configuration to 1 0 0 but this did not solve point 3 above.
5. Some additional info for context, which may be important: I have an AWR2944 ES1.0 device and I'm using SDK version 4.03.00.01 (as latest SDK does not support ES1.0 but only ES2.0)

In terms of priority, I can use FRAME_START on G15 for now so my highest priority is finding the cause of the additional pulses on FRAME_START for the first time load of a profile config after a reboot.

FRAME_START pulse for 1 frame, no additional pulses - 2nd time loading profile config after a reboot:

FRAME_START lots of additional pulses (many more not captured on oscilloscope time scale) on the first load of a profile config after a reboot:

Many thanks,

Mark

Hi Mark,

As per my understanding when you call the Profile Config API

you might be calling this with 0 value for PF_CALLUT_UPDATE filed. So this will lead to the RF analog parameters being readjusted via a calibration. 

Can you confirm if this is 0 or 1 in your case and what is your observation if you make this 1( if it was 0 in your case).

Thanks,

Pradipta.

Hi Pradipta,

Thanks for this info.

I'm struggling to find where this parameter is configured / where I can set the value to 1. I am using the demo source code, focusing on TDM for now (located C:\ti\mmwave_mcuplus_sdk_04_03_00_01\mmwave_mcuplus_sdk_04_03_00_01\ti\demo\awr294x\mmw).

In rl_sensor.h file I see rlProfileCfg which contains pfCalLutUpdate and this corresponds to the document snippet you shared above.

I'm using SDK version 4.03.00.01 and I'm not sure where this can be configured. Can you help me find where this can be modified?

Thanks,

Mark

Hi Mark,

So, in the demo application it is not feasible to make this change. In Demo application does not incorporate every single feature that the mmwavelink libraries offer. 

Thanks,

Pradipta.